OAuth 2.0

An OAuth access token tells a resource server:

"This app is allowed to access these resources on behalf of this user."

An access token isn't a standardized identity assertion for logging the user into your app. It can be used as part of a larger authentication system, but it requires additional work. For standardized identity verification, you can use OpenID Connect (OIDC), an identity layer built on OAuth 2.0.

• Resource owner: The user granting access
• Client: Your application
• Authorization server: Authenticates the user, obtains authorization, and issues tokens
• Resource server: The API that accepts access tokens and protects the user's data

1. Your app creates a one-time state value bound to the browser transaction and a PKCE verifier and challenge.
2. Your app redirects the browser to the authorization server with the requested scopes, state, and PKCE challenge.
3. The user authenticates with the authorization server and approves the requested access.
4. The authorization server redirects the browser back to your registered callback URI with a short-lived authorization code and the state value.
5. Your app verifies that state matches the browser transaction, then exchanges the code and PKCE verifier for an access token from the authorization server.
6. Your app uses the access token to call the resource server.

Scopes define what access you're requesting, for example:

• read:user
• email
• repo

Request the minimum scopes required. Overbroad scopes increase the blast radius if a token is stolen.

There are two main types of tokens in OAuth 2.0: access tokens and refresh tokens:

• Access tokens: Are typically short-lived and authorize direct calls to a resource server.
• Refresh tokens: Are typically longer-lived and are used to obtain new access tokens without requiring the user to re-authenticate.