OAuth 2.0 Authentication Protocol
OAuth 2.0
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
Authentication vs Authorization
In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
Authentication:
- Used to identify the validity of the user’s identity
- Asks the user to identify it’s identity using valid credentials
- Usually done before authentication
- Is validated generally through ID tokens
Authorization:
- Used to identify what user can or cannot access.
- Verifies whether access is allowed through policies and rules
- Generally comes into picture once user is authenticated.
- Information is transmitted using Access tokens.
OAuth is used to authorize a service for specific functions rather than authenticating users.
UseCases
- Photo printing applications can use pictures on Google Photos by authenticating via Google.
- A social interaction website for gamers can show the users’ scores on different gaming platforms.
- An online gym platform can access summarised health data of users to curate specific challenges for the user.
OAuth Actors
The actors in OAuth flows are as follows:
- Resource Owner: owns the data in the resource server. For example, I’m the Resource Owner of my Facebook profile.
- Resource Server: The API which stores data the application wants to access
- Client: the application that wants to access your data
- Authorization Server: The main engine of OAuth
The resource owner is a role that can change with different credentials. It can be an end user, but it can also be a company.
Clients can be public and confidential. There is a significant distinction between the two in OAuth nomenclature. Confidential clients can be trusted to store a secret. They’re not running on a desktop or distributed through an app store. People can’t reverse engineer them and get the secret key. They’re running in a protected area where end users can’t access them.
Public clients are browsers, mobile apps, and IoT devices.
OAuth Tokens
Access tokens are tokens client uses to access the Resource Server (API). They’re meant to be short-lived, with TTL being in hours and minutes, not days and month. You can get access tokens with public clients. They’re designed to optimize for internet scale problems. Because these tokens can be short lived and scale out, they can’t be revoked, you just have to wait for them to time out.
Refresh Tokens are the tokens that the client uses to get a new Access token. Their lifetime is much longer than access tokens i.e days, month and years.
Refresh tokens can be revoked. This provides the server with the ability to force the clients to rotate secrets. Clients can use refresh tokens to get new access tokens and the access tokens hit all the API resources. Each time the access token is refreshed the client gets a new cryptographically signed token. Key rotation is built into the system.
OAuth Flows
- Authorization Code Flow: Authorization Code Flow exchanges an authorization code for a token. This flow has a prerequisite of client already having the app’s secret key.The app receives the user’s authorization code and forwards it along with the Client ID and Client Secret, to the OAuth authorization server.The authorization server generates an ID Token, Access Token, and an optional Refresh Token, before providing them them to the app. The web application can then use the Access Token to gain access to the target API with the user’s credentials.
- Client Credentials Flow: The Client Credentials Flow allows applications to pass their Client Secret and Client ID to an authorization server, which authenticates the user, and returns a token. This happens without any user intervention, because the “user” is often a machine or service role.
- Resource Owner Password Flow: The Resource Owner Password Flow asks users to submit their credentials via a form. Credentials are transferred to the backend and may be retained for future use, before an Access Token is granted. It’s essential that the app is completely trusted. Therefore, this flow is generally not recommended.
- Implicit Flow with Form Post: The web app requests and receives tokens via the front channel, without requiring extra backend calls or secrets. With this process, you don’t have to use, maintain, obtain or safeguard secrets in your app.
- Hybrid flow: A hybrid of multiple approaches
- Device Authorization Flow: Authorizing devices instead of users
- Authorization Code Flow with PKCE
Conclusion
OAuth 2.0 is an authorization framework for delegated access to APIs. It involves clients that request scopes that Resource Owners authorize/give consent to. Authorization grants are exchanged for access tokens and refresh tokens (depending on flow). There are multiple flows to address varying client and authorization scenarios. JWTs can be used for structured tokens between Authorization Servers and Resource Servers.
References
- https://oauth.net/2/
- https://github.com/golang-jwt/jwt
- https://github.com/dgrijalva/jwt-go
- https://www.youtube.com/watch?v=-Scg9INymBs
- https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization
- https://tools.ietf.org/id/draft-ietf-oauth-use-cases-03.html
- https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth
- https://frontegg.com/blog/oauth-flows