A side note: both the authorization code and the token flows are passive flows, i.e. they are designed for browser applications. They differ however in how and when the access token is acquired.
|Authorization code flow||Token flow|
|User navigates to an application page||User navigates to an application page|
|User provides her credentials||User provides her credentials|
|The authorization server redirects back to the application’s page and attaches the one time code to the response||The authorization server redirects back to the application’s page and attaches the access token to the query string (in an uri fragment)|
|The access token can be used from the server to access other services|
As you can see, in the authorization code flow the access token is available at the application’s server side, in the token flow the access token is available in the browser at the client-side.
To show how the token flow is implemented I need a simple wrapper for AJAX requests as the very last step of the flow will involve a call to a profile endpoint of the authorization server that will exchange the access token for basic user information (email, given name, surname, details vary depending on the actual OAuth2 provider).
The actual token flow is then as follows:
And that’s really it!
As you can see I attach a handler to the window’s load event. Here I check the uri fragment – if there is no access token, I assume this is the initial request and thus I redirect the request to the OAuth2 server.
If, however, the access token is here in the uri fragment, I can use it to create a request to the profile API passing the token in the authorization header (the format of the header is “Authorization : Bearer [token_here]”). Depending on the actual profile API, the returned object contains the information on the authenticated user.