Last Updated on September 18, 2023 by Aram
Open Authorization or OAuth 2.0 is a security protocol and has evolved into an industry standard to apply authorization for digital solutions.
The combination of solid security standards and enhanced customer experience with the different flows makes it optimal to implement OAuth 2.0 on virtually every type of application.
History of OAuth
Originally the idea was introduced by one of the lead engineers in Twitter in 2006.
The first version of OAuth as a Protocol was defined as RFC and introduced in 2010.
OAuth 2.0 was then introduced in 2012.
OAuth 2.0 is the de facto security protocol adopted by top companies like: Google, Facebook, LinkedIn and others.
OAuth 2.1 is draft that includes few modifications on OAuth 2.0 with collective enhancements to further improve the security.
General Terms
Authentication
This is the process to identify the user/client. Do we know this client/user?
Authorization
Does this authenticated client/user have the needed permission to access this specific API or resource?
Bearer Authentication
Or Token Authentication is the process that involves accessing protected resources by providing bearer tokens.
Bearer Token
A cryptic string passed by the client to the resource server via the HTTP authorization header.
Resource Server
The backend that retains the data related to the users.
Authorization Server
The server or provider that issues and validates the tokens.
Resource Owner
The end-user who is trying to do certain operations on the client, like searching for previous orders, saved addresses, performing checkout…etc.
OAuth Client
The front-end application that is built to be served for the users and that has registered as a client in the authorization server. The client type vary between mobile, web, desktop, backend or any smart or IOT device.
Confidential Client
A trusted client (web app) that can be trusted to keep the client secret and configurations in a safe place.
Public Client
A front-end client like SPA or mobile app that cannot safely store a secret.
Access Token
A specially encrypted string that includes data related to the user’s access grants for the resource server (like Web APIs).
Refresh Token
Another token that is provided to the client to be able to refresh the access token silently without the user’s consent or login each time.
Scope
The permission(s) granted for the client to access the resource. Scope is usually a list of agreed-upon words separated by space.
Authorization Flow
The major type of authorization process that will happen between the client, the authorization server and the resource server.
Grant Type
This represent type of credentials to be used within the specific authorization flow.
User Consent
The agreement screen that is shown to the user specifying which application is trying to access which scope or information that belongs to the user.
Authorization Flows in OAuth 2.0
Here are the different flows supported by OAuth 2.0:
Client Credentials Flow
Should be used only when performing service-to-service integration where there is no User interface or interaction.
Authorization Server would generate a Client ID and Client Secret for the Client.
Client will have to provide the Client ID and Client Secret to Get Authenticated and receive an Access Token.
Client credentials flow doesn’t generate refresh token.
Authorization Code Flow
Best used with web applications running on the server like ASP.NET MVC.
Users trying to login are redirected to browser-based user login and consent screen.
After a successful login, the authorization server will redirect the user to the redirect url with the authorization code passed in the query string.
Application reads the authorization code and exchanges it with access token from the authorization server.
This is most recommended way to secure confidential clients not public clients.
Public clients can also use Authorization code flow but require another level of security which is PKCE.
Authorization Code Flow with PKCE
PKCE (spelled as Piksi) or Proof Key for Code Exchange An extension to the Authorization Code Flow.
This is the same authorization code flow but with another dimension which is the Proof Key for Code Exchange.
PKCE introduces the concept of code verifier and code challenge.
Here is how it works:
A client generates a cryptographically secure random key (code verifier).
Then the client hashes the code verifier using a strong hashing algorithm like SHA-2 (sha256).
After that, the client sends a request for authorization server to generate authorization code and passes the code challenge and method used as 2 extra parameters.
Authorization server replies with the authorization code to the redirect url.
Client reads the authorization code and sends another request for the authorization server to exchange the authorization code as well as the code verifier with an access token.
It is similar to sending a dynamic client secret on each authorization session instead of sending the fixed client secret.
Motive behind PCKE
PKCE is mainly used to mitigate a fake client trying to intercept the authorization code response by verifying the original OAuth requester.
The fake client won’t be able to generate the code challenge since it doesn’t have the code verifier.
PKCE is the most recommended and secure flow to implement when trying to authorize and secure public clients.
Device Code Flow
Used with devices that don’t support having or running a browser, these include Smart TVs, Smart Home devices.
The process starts when the user connects the smart device to do account sign in.
The device will connect to the authorization server, passing a client id that is specific to the device.
The authorization server will return to the device a set of data like device code, verification url and others.
The user will have to access the URL from any laptop or mobile and enter the device code shown on the smart device.
In the meantime, the smart device will keep pinging the authorization server to check for an access token response.
The smart device will use the interval to check the authorization server if the user has logged in successfully and thus retrieve an access token response.
This flow also supports refresh token so it would do silent refresh for the access token without asking for another device login.
YouTube on TV is popular use case for the Device Code Flow.
Implicit Flow (Deprecated)
This is the most basic flow for authorizing public clients.
The client receives the access token via the browser’s URL after the authorization server redirects the user to the redirection URL.
It isn’t considered the most secure, and recently is deprecated as it doesn’t include client authentication: The access token is publicly shared over the redirection URL on the same device.
Used when users have credentials (username and password),
Credentials would be provided via a web or mobile form for the client and then relayed to the authorization server.
The authorization server would then validate the credentials and grant the access token to the client.
Public clients are discouraged from using this flow because:
It involves handling user passwords.
It requires passing Client Secret, which public clients cannot safely keep them.
This flow should be used with confidential clients where these are trusted to handle the user passwords and are able to safely keep the client secret.
Token Types
Tokens can be classified by the formatting they are built with:
Opaque Token
A special token format that can only be validated through the authorization server that provided the token to the client.
Json Web Token (JWT)
A Self-Contained token that is encoded and digitally signed.
A JWT contains three parts separated by dots:
{Header}.{Payload}.{Signature}
Header
Includes the algorithm used to sign/encrypt the JWT, usually it is HMAC SHA-256 or HS256.
Payload
Contains the claims which are key,value pairs of important details about the resource owner and some standard information like issuer, audience, subject, issued at and others.
Signature
Encoding of the header and payload hashed using the header’s algorithm with a secret.
OpenID Connect
This is an authentication protocol that is built on top of OAuth 2.0, it is used to enable easy access for users by introducing single-sign on (SSO).
When a user or client is authenticated, the OpenID Connect to or OIDC provider returns an ID token, this token is a JWT format and include claims related to the authenticated user’s details from the user’s profile.
OAuth 2.0 Providers
There are 2 types of providers for OAuth 2.0 implementations:
Plugin solution for your own
OpenIddict
This is an open source implementation for OpenID and OAuth 2.0, it enables you to configure and setup an authorization server with your .NET and ASP.NET Core application.
IdentityServer4
Though it has been deprecated as of November, 2022, but it is worth mentioning here as it used to be the best solution to build an authorization server and integrate it within your own applications.
It is similar to OpenIddict.
Identity Server has moved and become a paid service provided by DuendeSoftware.
Identity Providers
KeyCloak
Keycloak is an open source software product to allow single sign-on with identity and access management aimed at modern applications and services.
It provides user federation, strong authentication, user management, fine-grained authorization, and more.
Auth0
Provides a comprehensive identity and access management solution with full-fledged authentication and fine-grained access control authorization.
Microsoft Identity Platform
This is a cloud-based solution that leverages the OpenID Connect and OAuth 2.0 to provide authentication and authorization using the Active Directory as a main source Azure AD B2B, as well as through other social media accounts, Azure AD B2C
In OAuth 2.1
This is an ongoing effort to introduce few specification changes on the current OAuth 2.0, with the below main changes:
- The Implicit grant is removed
- The Resource Owner Password Credentials grant is removed
- PKCE is the only way to implement authorization code flow
- Bearer tokens are longer permitted in query strings
You can read the full specification draft here:
Summary
This was a quick guide to learn OAuth 2.0, there are still so many technical details behind the OAuth 2.0 and how it is implemented.
We got introduced to the different terms linked with and related to OAuth 2.0, and learned about the different authorization flows of OAuth 2.0.
Also we learned about the popular format for access tokens, Json Web Token (JWT) and its structure.
Finally we introduced the most popular and solid implementations for OAuth 2.0 and identity access management solutions, and peaked on the on-going efforts to introduce OAuth 2.1
Collaborations and Sponsorships
If you want to learn about the available opportunities to collaborate and work together, please check this page:
https://codingsonata.com/sponsorships-and-collaborations/
References
To learn more about OAuth 2.0, you can check these references:
The OAuth 2.0 Authorization Framework
OAuth 2.0 and OpenID Connect (OIDC) in the Microsoft identity platform
Bonus
Enjoy the complete French Suites composed by the brilliant Johan Sebastian Bach
Played by Pianist Professor Yuan Sheng
Have a fruitful learning journey!