Getting Started with OAuth 2.0

Security Properties

The Authorization Code flow does not expose the access token to the resource owner’s browser. Instead, authorization is accomplished using an intermediary “authorization code” that is passed through the browser. This code must be exchanged for an access token before calls can be made to protected APIs. The exchange process only succeeds if a correct client_secret is passed with the request, ensuring confidentiality of the access token as long as client security is maintained. Unlike with the Implicit flow described in Chapter 3, this confidentiality also extends to the resource owner, meaning API requests made with the access token are directly attributable to the client and its developers. Perhaps most importantly—because the access token is never sent through the browser— there is less risk that the access token will be leaked to malicious code through browser history, referer headers, JavaScript, and the like.

Although there is less chance of the access token leaking because it’s not exposed to the browser, many applications using this flow will store long-lived refresh tokens in the application’s database or key store to enable “offline” access to data. There is additional risk when an application requires long-lived offline access to data, as this creates a single point of compromise for accessing data belonging to many users. This doesn’t exist with other flows, such as the flow for client-side web applications (see Chapter 3). Even with this additional ...