Demystifying OAuth & Open ID Connect

In today’s digital landscape, ensuring secure and seamless access to resources and services is paramount for both developers and users. Two critical protocols that have emerged to address these needs are OAuth and OpenID Connect (OIDC). OAuth is a security standard that allows a user to authorize one application to access resources they own in another application. This process involves delegating authorization, but it’s important to note that OAuth itself does not handle authentication. While SAML can be used for authentication, OAuth initially did not address this aspect. To fill this gap, OpenID Connect (OIDC) was developed on top of OAuth specifically for authentication purposes. Before diving into the OAuth flow, let’s quickly review some key terminology.

Let’s consider a concrete hypothetical example to illustrate these concepts. Suppose there’s an app called MagicPhoto that specializes in photo editing and offers a variety of cool features. All your photos are stored in Google Photos. To perform its functions, MagicPhoto needs to access some of your photos from Google Photos, edit them, and then upload the edited photos back to your Google Photos account.

Authentication

Authentication is the process of verifying the identity of a user, device, or entity. It ensures that the entity is who or what it claims to be. Authentication is typically the first step in any security protocol. For example, username & password can be used as authentication. Now a days it’s common to use another secondary authentication (Multi Factor Authentication) using phone or email for security reason. AuthN is a common term used for authentication. In our example you have to prove to google authentication server that it is you using username and password and possibly along with MFA.

Authorization

Authorization is the process of determining whether a user, device, or entity has the right to access specific resources or perform certain actions. It occurs after authentication and defines what an authenticated entity is allowed to do. It mainly determines what operations are allowed for the Authenticated User. AuthZ is a common term used for authorisation. In our example you have to give permission to MagicPhoto so that it can access only a special folder that has few photos that you plan to be edited. You are basically authorising the APP to read and write photos on that specific folder only. App won’t be able to access any other photos.

In short Authentication is proving who you are and Authorization is the permission that you have. If you are NOT clear with Authentication and Authorization, I’d request NOT to proceed further. Do google and have clear understanding of this. Rest of the discussion assumes you have clear understanding of both.

Resource Owner

The user or entity that owns the protected resources and can grant access to them. Typically, this is the end user. In our example you are the resource owner.

Client

An application that requests access to resources on behalf of the resource owner. This can be a web app, mobile app, or any other type of application. In our example MagicPhoto is the client.

Authorization Server

The server responsible for authenticating the resource owner and issuing access tokens to the client. It handles the authorization process. In our example it is Google Authorisation Server.

Resource Server

The server that hosts the protected resources. In our example your photos are protected resource and Google Photo is the Resource server whare your photo resides.

Note that Authorisation Server and Resource Server can reside within same server or different server. It depends on the implementation.

Trust between Client and Authorization Server

There needs to be some trust establishment between Client application and Authorisation server. Usually Authorization server provides a way for client application to be able to register with it. Here is an example of registration process of an client application with google. Once a client application registers with Authorisation server it usually gets application ID and Secret which is equivalent to username and password. Now client has to use those credential for communication with authorization server. Here is an example.

My google app ID & Secret

Redirect URL

Also you can see redirect URL is registered with google. Google will redirect to one of this URL with authorisation code.

With these understanding we are poised to look at the flow.

OAuth Flow

Now let’s us put our example in to the flow. For MagicPhoto to be able to access google photo, it has to first register the app with Google Auth server and generate APP Id & Secret.

1. You have to first login to the MgicPhoto App. Note that this is the security for MagicPhoto App. We are gonna concentrate on this.
2. MagicPhoto app might give you some UI to import photo from Google Photo or want to have a read or write access to specific photo storage. This permission scheme depends on what Google Photo supports. Once user made a choice, redirection to Googles Auth Server will happen. Request has to carry App ID & Secret and redirect URL.
3. Google Auth Server will validate App ID, Secret and redirect URL, if all are valid, it will present login page for the user.
4. You will be presented with the list of permissions that you are going to approve and of course login page to authenticate.
5. Enter the credentials
6. credentials will be sent to Google’s server for authentication. additionally there can be MFA. But that entirely depends on Google Auth server and you.
7. Once Authentication is successful, an authorization code will be issued by Google Auth server. Response will be a redirection to the redirect URL and authorization code will be sent along with.
8. Authorization code is short lived and redirect URL would mostly be some URL in magicPhoto server. Once MagicPhoto receives the Auth code, it can reach out to Google auth server again to get Access Token and Refresh Token. JWT token are the most popular format that is used for those token.
9. Google Server will verify Auth Code and issue Access & Refresh token. This access token will have authorisation information that you have approved at step 4. Usually validity of access token is in terms of minutes and that of Refresh token is in terms of Days. Refresh token is used to obtain access token again and may be used to obtain another refresh token as well.
10. MagicPhoto will store these tokens secretly. These are bearer token and it is very important to protect those. Now Magic server can access resource from resource server. Resource server will check the token for kind of authorisation the token provides and if requested resource are authorised as per token Resource Server will share the resource with MagicPhoto.
11. MagicPhoto can time to time get new Access Token using the refresh token. If Google Server allows refreshing the refresh token, MagicPhoto can refresh the Refresh token. Otherwise after Refresh token expiry, user has to authenticate again and complete the entire flow again.

From the flow you can see that you have authorised MagicPhoto with few permissions so that it can access your photo stored in Google Photo. Most important aspect of this process is that MagicPhoto doesn’t know your credentials and sharing that wasn’t necessary. This is the exact use case that OAuth solves.

Trust Between Resource and Authorization Server

The token that are issued by the Authorization Server are signed by the Auth server. Resource Server must validate the signature to confirm that the token are intact and NOT tempered. Also there has to be understanding between two server regarding the access permission on various resource. Auth server must embed those permission information in to the access token and Resource server must understand those.

Open Id Connect (OIDC)

OIDC is an extension of OAuth2.0 and built on top of OAuth. But the question is why was it needed ? What problem it is solving?

If you have looked at closely, client (MagicPhoto) is our example has no way to validate the user. All informations are related to authorisation are passed on to the access token.

Buy why is it a problem ?

It’s NOT a huge problem per say, but having identity can provide lots of advantage. For example user login to the MagicPhoto app itself. This can completely be avoided if identity information is also included in the OAuth. Authorisation Server already authenticated the user, now If Authorisation server provides identity information back to the client, client doesn’t need to maintain their own login for the user. they can simply stores the authenticated user details in their systems and when user tries to access clinet (our example MagicPhoto) again, it can get the user authenticated by the Authorisation Server. This way entire authentication system in the client side can be totally removed. And that is what exactly happens when you see login with Google, FaceBokk etc. when trying to access some other service.

Let’s look at the Change on OAuth that makes OIDC

The above flow remain almost identical, but here are the differences.

• At step 2 with the request a scope is set to “openid” and sent along with the request. This scope tells authorisation server that it is OIDC and they should share identity information as well.
• At Step 9, an additional token names id_token will be issued by the authorization server. This id_token will have identity information of the user. This id_token has been standardised as JWT token.

id_token format

Here is the link for OIDC Details

To make an analogy OAuth is like a hotel access card where there is NO print on the card about the hotel details, on the other hand OIDC is the access card where hotel access is given and also hotel details, contact etc informations are printed on the access card so that we know which hotel this card belongs to.

Conclusion

In conclusion, OAuth and OpenID Connect (OIDC) are essential frameworks in the realm of modern authentication and authorization, offering robust, secure methods for managing user access in web applications. OAuth provides a flexible authorization framework that allows users to grant third-party applications access to their resources without exposing their credentials. Meanwhile, OIDC extends OAuth to include authentication, providing a standardized identity layer that ensures the user’s identity is verified before access is granted. Together, these protocols enhance security, streamline user experiences, and facilitate the development of scalable, interoperable systems, making them indispensable tools for developers and organizations navigating the complexities of digital identity and access management.

References:

RFC 6749: The OAuth 2.0 Authorization Framework

OpenID Connect Core 1.0 incorporating errata set 2