OAuth 2.0: In the authorization code flow, who eventually hands the access token to my web browser?

Question

I am learning OAuth 2.0.

In OAuth 2.0, the term “grant type” refers to the way an application gets an access token.

In the Implicit Flow, the authorization server will redirect the browser back to redirect_uri specified by the application, adding a token and state to the fragment part of the URL. So I take it that the end user's web browser will get the access_token value.

However in the code flow, it seems that the Auth server will give a temporary code to my web browser, and my web browser then send http request to the application with this code attached. And then the application calls the Auth server's /oauth/token endpoint to exchange that temporary code with an access token, so it finally gets the access token from the auth server.

Is that the end of the story then?

Does the application go one step further to give the access token to my web browser?

I have always assumed that for me to be able to interact with the application (sending more and more HTTP requests to it as I am using the application), every http requests would have an access token attached, so that the request is valid to hit the application's endpoints.

But it seems that in the code flow, I, as the end user, do not have the access token in my browser after I have completed the OAuth code flow and started to interact with the application?

How does the application know that I am indeed who I am then?

Answer 1

The browser doesn't need the access token as it can't do anything with it. Browsers do not understand or handle access tokens in the same way as they understand and handle cookies.

In the implicit flow, the token is sent to the browser, but it is assumed that you have your own application running in the browser (typically a Single Page Application) which will read the token and attach it to any subsequent requests. Or use that token's contents if you're using OpenID Connect and ID tokens to authenticate users.

When the browser sends the authorization code to your application and your app exchanges that for an access token, then your app should establish a session for the user in that browser. Then, when the same user makes requests to your app, you can use the access token assigned to that user session.

Typically, your app would use this access token to call some other APIs, but if you need that access token only to identify the user and let the user access your app, then most probably what you really need is plain old sessions, not OAuth.