A lot of what I'm reading about standards like OAuth suggest that you never want the access token you issue to be made available directly to the client, and that's why things like the Implicit Grant are often criticized.
...which offered an interesting suggestion of proxying requests to the API through a thin server side component, so that the single page app could authenticate with the proxy, get back an encrypted session cookie, and then make requests to the proxy server which would attach the user's access token to the requests before forwarding them on to the actual API.
What I'm wondering is how this is any more secure than just handing the client an access token? If the attacker would've been able to get the access token, surely they can get the cookie storing the session information which is just as good as the access token for making requests to the API?
Why is it that we consider encrypted cookies with session details in them safe, but trusting the client with the actual access token is considered insecure?
Is the real difference just that an API with no direct client-side access is considered a secure, private API, and any API that needs to be accessed by the client side in any way (even through a proxy) needs to be treated as a public or open API, and you just have to accept the trade off of the risk of someone potentially being able to forge requests if they were able to get their hands on the session cookie or access token?
What is actually the most secure way for a single page application to prove it's identity to an API?