Introduction
This article demonstrates core concepts of OAuth2.0 and OpenID Connect. At the end of this article, you will have a clear understanding on the below points:
- What is OAuth2.0?
- Actors in OAuth2.0 framework
- Brief OAuth2.0 workflow diagram
- What are Authorization Grants types?
- When to choose which grant type?
- What are Issues not handled by OAuth2.0?
- Why we need OpenID connect?
- What is OpenID connect?
- When OpenID Connect can be useful?
- Brief workflow diagram using OIDC
- Example of OpenID Connect and OAuth2.0
- A modern applications architecture using OAuth2.0 and OIDC
- Implementation Approach
- Related reads
What is OAuth2.0?
OAuth stands for Open Authorization.
It's used for delegated authorization to delegate the responsibilities of user authorization to some other service rather than managing them on its own.
It enables a client’s app to use resource servers on behalf of resource owners on exchange of access token.These resources could be photos, contacts that are usually stored with other providers. OAuth does this by granting the requesting client application a token, after user approves access. Each token grants limited access to specified resources for a specific period.
OAuth is not a password sharing mechanism or protocol. It is“How can I let third party website access my data without giving my password”. The misunderstanding comes down to Authentication versus Authorization. Authentication is who you are while authorization is what you can do. Authorization depends on authentication but they are not interchangeable.
If we resemble the same with real life example like “check-in into a hotel”. When you check in to a hotel, you present to the reception with your driving license or passport. This establishes who you are i.e. your identity. Then hotel receptionist issue you a key card that encoded with what you have access to, which will include your room access, it might also include the gym or swimming pool access too. That is your authorization. The best part is that your personal and billing information never leaves the front desk. This is OAuth.
In terms of OAuth terminology, you are the client. The front desk is the authorization server, which evaluates the authorization policies. The key card is an access token, representing the result of those policies. In addition, your room, the gym, etc., are the resources you want to protect. Fundamentally, OAuth is an authorization framework.
Actors in OAuth2.0 framework
- User/Resource Owner
Owner of a user resource i.e. end-user who is giving access to some portion of his/her account.
- User-Agent
Browser or native app.
- Client Application
The application that is attempting to get access to the user’s account or a resource on Resource Server i.e. APIs. This application could be website, desktop or mobile app.
- Authorization Server
The server where the client applications are registered. It holds user identities, authenticates a user, and ask him/her to grant client app to access protected resource hosted by a resource server and then issuing an access token to client app.
- Resource Server
The Web API or web service that hosts the secured and protected user resources and protected by OAuth. It shares user resources with client app in possession of an appropriate access token.
Brief OAuth2.0 workflow diagram
- The resource owner sends a request to the OAuth enabled client application
- The OAuth client submits an authorization request to the server, which validates that the client is a legitimate client of its service. OAuth authorization server authenticates the user and presents consent page. It then sends the authorization code to the OAuth client.
- The OAuth client uses the authorization code to retrieve an OAuth token from the OAuth server.
- The OAuth client presents the access token to the OAuth resource server.
- The resource server validates token with authorization server.
- The resource server provides the requested content to the OAuth client.
What are Authorization Grants types?
The Authorization grant type depends on the method used by the application to request authorization and grant supported by the apps.
There are four Authorization grant types defined and used in different context.
- Authorization Code - Used for back-end web apps, native apps
- Implicit - Used for SPA app executing on the user's browser.
- Client Credential - Used for machine-to-machine authentication or service accounts where there isn't a user involved
- Resource Owner Password Credential - Used for highly trusted apps, not recommended.
|
OAuth flows
|
Need frontend
|
Need backend
|
Has user interaction
|
Needs client secrets
|
|
Authorization Code
|
Yes
|
Yes
|
Yes
|
Yes
|
|
Implicit
|
Yes
|
No
|
Yes
|
No
|
|
Client Credentials
|
No
|
Yes
|
No
|
Yes
|
|
Password Grant
|
Yes
|
Yes
|
Yes
|
Yes
|
When to choose which grant type?
The below diagram depicts the simplest way to choose a grant type of your application based certain conditions. This is just a very high level and based on your need you can choose accordingly.
What are Issues not handled by OAuth2.0?
OAuth2.0 leaves many details up to implementation.
- It supports scope, but scope names are not specified.
- It supports access token but access token formats are not specified.
- Since the only thing it handles is authorization, the framework does not support end-user authentication by itself.
Why do we need OpenID connect?
There are many situations where the application needs to know who logged in and the API certainly needs to know who the user is.
However, OAuthdoes not say anything about how to do that.That is why we need something beyond OAuth which is OpenID connect.
Other thing to keep in mind about OAuth is that it was originally created and designed for third-party apps, like it the Spotify app is trying to access your contacts from Google. However,things have matured over time; the OAuth framework actually provides a very good solution for first party apps as well.
What is OpenID connect (OIDC)?
It is an identity layer on top of OAuth2.0. The two fundamental security concerns, authentication and API access, are combined into a single protocol called OpenID Connect.
OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. The identity provider signs it.
In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice for instance scopes, endpoint discovery, and dynamic registration of clients.
It has become the leading standard for single sign-on and identity provision on the internet.
Simple JSON based identity token (JWT) delivered via OAuth2.0 flows designed for web, browser based and native application.
With ODIC, a number of specific scope names are defined that each produce different results. Scopes are space separated lists of identifiers used to specify what access privileges are being requested. Built in scopes are,
- openid: This is mandatory scope
- profile: request access to default profile claims like name, picture , birthdate etc.
- email: requests access to email and email_verified claims
- address: request access to address claim
- phone: requests access to phone_number and phone_number_verified claims
Claims are name/value pairs that contain information about a user as well as meta-information about OIDC service.
It provides structure to a user profile, and allows you to selectively share it. To continue with our analogy from earlier, let us say you want to eat at the hotel restaurant. With OIDC, you can share your food allergies, and those alone, but not your e-mail address. Allowing you to share specific things is just authorization all over again. In addition, that is right; OpenID Connect is just a special case of OAuth. It is designed specifically for single sign on use cases, and sharing profile information.
When can OpenID Connect can useful?
There are three situations where using OIDC can useful.
Instead of asking users to create yet another account in client website, we could take advantage of OIDC to integrate with an identity provider to reuse their existing accounts on an identity providers like Google or Facebook etc.
OpenID Connect can be useful is when the protocol is used to create a hub of identity providers. In this scenario, instead of making your application communicate with multiple providers, you can make it connect to a single identity provider that acts as a hub for the others.
OpenID Connect can be works as a proxy for other protocols like SAML.
Brief workflow diagram using OIDC
BThe below workflow depicts how OpenID works internally and serves user requests step by step, including authentication delegation to protected resource access using access token.
Example of OpenID Connect and OAuth2.0
One of the simplest examples ever to understand the difference between OpenID Connect and OAuth2.0:
OpenID Connect: Sign in with Google, Facebook, LinkedIn (i.e. third party identity provider) or your own identity server in your application (i.e. Azure AD or IdentityServer4 etc.). As an example, we can see OpenID configuration of Google on
here.
OAuth2.0: This could be the consent that you/resource owner are granting to the client app and authorizing the app to access protected resources.
A modern application's architecture using OAuth2.0 and OIDC
Below is the architecture of a modern application where client application could be Browser-based app, Native app and Server-based app that can communicate with Web App and WebAPIs. OIDC and OAuth 2.0 combination is the best approach to secure those applications nowadays using a security token service.
[Image Reference: https://identityserver4.readthedocs.io/]
Implementation Approach
- If you want to allow your app to use third party OpenID provider like Google or Facebook etc., then easily integrate them with your application using documentation provided by the respective providers.
For example, Google OpenID provider
- You can build your Identity provider. For example - IdentityServer4 which is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core.
Related reads
To understand the detailed workflow of different authorization grant types, please read this
article.
Conclusion
In this article, we have gone through some of the core concepts of OAuth2.0 and OpenID Connects – What is it? Why do we need it? How does work? When trying to understand OAuth, it can be helpful to remember that OAuth scenarios usually represent two unrelated sites or services trying to accomplish something on behalf of users or their software. Whereas OpenID Connects (ODIC) enables different types of applications to support authentication and identity management in a secure, centralized, and standardized way.
Vinay AyinapurapuPosted Apr 27, 2021, 6:48 AM
Nicely explained. Appreciate all the efforts that are taken to put this information.