360 Degrees around the OAuth

OAuth refers to the Open Authorization mechanism/protocol, which works at the authorization level rather than the Authn level. But yeah, For client application that uses the functionality of OAuth can perform Authn through Authz via auth server. Often People confuse themselves with these sibling terms. So let’s understand them first:

Authentication means proving that you are a legitimate user that holds valid credentials (username & password) for that particular application/system. For example, you enter your email and password on your Gmail account login page to access it. On the other hand, Authorization involves providing the privilege to access functionality on behalf of the user (basically who holds credentials) without directly sharing the credentials. For example, allowing the third-party app say Spotify to directly share your music as a post on Facebook without sharing your Facebook credentials to Spotify.

let’s move back to OAuth,

So, How it works, Let’s think as a developer, application X doesn’t have an access to your application Y credentials but you are allowing X to perform action A on Application Y via providing delegate access. Here, you need to authorize X to do so which can be done by requesting Authorizing server of Y. In turn, the authorization server provides an access token that can be used to transact from the resource server (which handles the DB operations)of Y or perform any action at Y using prebuilt APIs that feed on the provided token by the Y authorization server.

OAuth Flow

3-legged & 2-legged

Above represented the general OAuth flow which is a 3-legged OAuth which means the involvement of the user (Resource Owner)along with the auth. server and the client that’s why 3 legged because of 3 connection links. 2 legged is also there if a user is no more involved in the OAuth process. 2 legged OAuth probably your client and servers communication in your application if following stateless mechanism say jwt/app access tokens. It involves no user involvement like the client using the jwt token to call the server’s API with the specific scope and functionalities. So, 2-legged seems where your client and server are related to the same application or a party whereas 3-legged mostly the client is of the outside domain and needs to specifically register to the OAuth party’s portal to get the client id and secret. Although it can be done or utilized in 2-legged as well.

AuthN of the user via OAuthZ for an application

Nowadays, applications to provide ease to users use social sign-ins that authenticate users as a legitimate ones on behalf of authZ via OAuth. That simply means if the OAuth client of the application can get the OAuth access token through a social media app auth server which shows the user as a legitimate to allow the user the access to the application without credentials of that application (kind of password-less way). This is known as Federated Authentication. For example. you just using your google account to log in and purchase on Amazon without having cred for Amazon.

To give it a try Pl. check out my other article here.

OAuth 2.0 & OAuth 1.0

Let me start with OAuth 2.0 ( RFC 6749), the version of OAuth has the flow as shown above in the figure mentioned (Authorization code grant). It starts with sending a request with the client_id and redirect_url to the OAuth server and allows the client to provide credentials directly to the authorization server. Then Auth server provides an authorization code to the OAuth client basically the application that wants authorization on behalf of the user. The OAuth client sends the request again to the OAuth server with authorization_code and redirect_url to receive the access token returned by auth server after code and redirect_uri verification. Now, the OAuth client use provided access_token which is a bearer token that doesn’t require any cryptographic functionality and is sent along with the headers generally when used by a server-side application. These tokens have the same behavior as the 2-legged flow jwt bearer tokens.

So following are the parameters that involve in the OAuth:

• client_id: It is provided to the client after registering it with the OAuth provider to identify the client. It should be included in the request to get the authorization code.
• client_secret: A confidential secret provided to the OAuth client.
• redirect_uri: the redirect URL to the application if the OAuth request is successful.
• grant_type: Need to add in the request this type(say Authorization code grant, implicit grant, etc.)
• access_token: Provide back in the JSON response by the auth server if the flow is successful. This access token can be used further to request action/ data from the resource server. They generally have a short life.
• refresh_token: This token is used to generate again new access tokens when they expire without revisiting the same process.
• expires_in: Both access_token and refresh_token have some expiry date or validity so need to reinitiate the flow if both expire.
• scope: This represents the access levels. For example, providing only email access to the OAuth client.

Typical request to Auth Server of reddit:

https://ssl.reddit.com/api/v1/authorize?response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8888%2Freddit%2Fredirect&scope=identity&state=crypticString &client_id= client_id

The typical response back to redirect URI:

http://localhost:8888/reddit/redirect?state=cryptic string&code=auth_code#_

The typical request to the resource server :

https://api.spotify.com/v1/artists/access_token/albums

Other Grant types

Implicit Grant: Currently, it is not in use because it is applicable for client-side applications (OAuth client based on the browser)that store and does everything through a browser which is not safe, place & sends access_token through browser only which is at risk of a leak. this grant does not have the provision of the refresh token. Security-wise this grant does not win.

Resource owner password Grant: This requires the user to enter the credentials. This grant is used when the third-party app is the first party app it is managed by the Authorization or OAuth server party to provide the access_token to the internal app to access the resource.

PKCE: This method prevents the breach of the Authorization code if happens when a request comes back from Auth server back to the client with the Authorization code. The malicious app or attacker can steal the code and request an access token from the Auth server. So to mitigate this, a proof key for code exchange is used that is known here as code_verifier or a cryptographic string which is sent after transformation via the code_challenge method along with the authorization request to the Auth server. So even in case authorization_code returned by the server to the OAuth client is breached by the malicious client or another app. It would need the code_verifier for requesting the access_token from Auth server. So, code_challenge = t(code_verifier) where t →SHA256 or cryptographic algorithm . More entropy will be better to avoid easy guessing of the code_verifier can help better implementation of the PKCE method. More about PKCE can be found at rfc7636.

Client credentials grant: Here, the client requires access_token to integrate the functionality for the entire app instead of the individual user. So this just involves client_id and client_secret to hit the request to auth server. For example, an OAuth client’s application requires google Maps integration or other service integration so directly client credential grant can be used. Sometimes complete DB access can be done through this grant when data is stored outside your application.

Refresh token grant: This grant type comes into action when access_token expires and without repeating the OAuth process client can retrieve new access_Token from refresh_token retrieved from Auth code grant flow. However, there is a risk associated with refresh_tokens as if they are captured by an attacker, the attacker can generate a new access token and can get the access to the system.

OpenID Connect

OpenId Connect is an identity wrapper or a protocol that works at top of OAuth 2.0 allowing the client to provide the access to the user based on authentication by the Authorization Server. This is a Federated authentication as mentioned above. It also allows the client to access the identity parameters of the user such as email_id, first_name, and last_name according to the scope declared from the Auth server. More information (say followers count, profile pictures, etc.)can also be gathered about the end-user from the auth server of the identity provider depending on the identity provider policies and requested scope. After successful authN of the end-user, the client gets the id_token along with access_token that contains information related to authn claimed. id_token is a signed jwt token having claim information like issuer identifier(iss), issued time(iat), expiry time(exp), etc.

Now, Moving to OAuth 1.0(rfc5849), OAuth 1.0 is not popular now, tending to depreciation or even depreciated by many service providers.

Registration of the consumer (client in OAuth2.0) works a pretty similar way in the OAuth1.0 to get the consumer key and consumer secret.

OAuth 1.0 uses a request token to request an access token to get the privilege to do actions and get the protected resources on the user’s behalf.

How the OAuth1.0 flow works :

The consumer first sends a request with consumer_key and consumer_secret to the service provider which in return grants a request token(oauth_token) to the consumer. Now consumer gets the authorization done by the end-user and hits the request with a few parameters i.e consumer_key,oauth_token, oauth_signature_method(HMAC-SHA1), oauth_signature, time_stamp, etc. The service provider now provides the access_token to the consumer by which it can get the user’s protected resources.

Twitter URL at the point of user authentication using OAuth1.0

https://api.twitter.com/oauth/authenticate?oauth_token=BOothwAAAAA BUjzeACSBgURus4U

OAuth 1.0 uses the cryptographic algorithm in order to prevent any unauthorized intervention. It uses theoauth_signature parameter and involves the signing of the request by the consumer and verifying through the service provider(Auth server). It provides generally 3 algorithms i.e HMAC-SHA1, RSA-SHA1, and PLAINTEXT. The application of cryptographic algorithms appeared as tricky to the developers which is one of the reasons for the drop in the usage of OAuth1.0. Also, as signatures are involved this mechanism does not require TLS/SSL(HTTPS) transport which is required and recommended in OAuth2.0. OAuth1.0 don’t support the concept of refresh tokens and offers long-lived access tokens which can increase the probability of illegal activity through them.

Beyond OAuth2.0

There are researches and drafts were going and went for OAuth 2.1 which generally enforces some more standard security considerations in OAuth 2.0 specs such as involvement of PKCE with authorization code grant, exact string matching of redirect_url, and some other changes.

So, still, there is a lot of scope for the improvement in the security aspects of OAuth 2.0 that can lead to the formation of OAuth 3.0 that may take time but surely gonna happen.

That’s it!

Thank you for reading! and hope it helped you!