OAuth is an authorization framework which enables third party applications to get limited access on protected resources over http in two ways.
1. On behalf of a user by Orchestrating an approval interaction between the resource owner and the http service
2. Using actual credentials of the user account by the third party application.
Second one is a use where we know it is a trusted and known third party application and the credentials are shared.
OAuth Roles
There are mainly four roles in the entire OAuth workflow.
1. Resource Owner: Resource owner is the entity or the person who owns the data and has the access to grant to a protected resource.
2. Resource Server: Resource server is the server where all protected resources are hosted.
3. Client: Any third party application which is trying to get user account details. This could be a mobile client, a simple rest client or postman or a website asking to login via google or Facebook account…
4. Authorization Server: Authorization server is the server which authorizes the client with its credentials and issues access tokens.
Client Id and Secret
Whenever any third party application need to access Oauth service, first it need to be registered. During client registration it is supplied with application name, website details and the redirect uri. Redirect URI is the uri which service will redirect it to after the authentication. Client gets a id and secret which is used in the subsequent url building.
Typical OAuth workflow
1. Client requests the resource owner for the authorization approval.
2. Resource Owner approves the resources access request and client receives the grant type.
3. Client uses the client id, secret along with grant type details to get access token.
4. Authorization server validates the details and provides the access token, refresh token and its expiry details.
5. Client uses the access token to access the protected resources.
OAuth Authorization Grant Types
OAuth authorization grant type is nothing but the credentials representing the resource owner authorization which client would present it to the authorization server requesting the access token. Client uses client id along with one of these grant types while getting access tokens.
There are four types of grant types.
1. Authorization Code
This grant type is used when the client is mostly a web server and it can interact with user for the approval.
Ex: Website redirects the user to the google account page where user authrorized and it issues the authroization code.
Workflow:
1. Client requests for authroization code with Authorization Server (Ex: Google, Facebook, Twitter..)- client id, secret, response_type=”code” and the scope of access.
2. Auth server redirects user to a page where Resource Owner gives consent (Either by explicit login if not already logged in).
3. Resource Owner approves the request.
4. Auth Server response back to Client with Authorization Code.
5. Client invoked Authorization Server with Authorization Code received asking for Access Tokens
6. Authorization Server validates authentication code and client credentials, issues access token.
7. Client access Protected Resources in Resource server using Access Token.
Note: Here access token is not exposed and used internally within the web app client.
2. Resource owner password credentials
Client already knows the user id and password of the resource owner which can be used to get the access tokens. Can be used when client is a trusted party and is allowed to share the credentials details.
Workflow:
1. Client requests for access token by submitting – client id, secret, user id and password of the resource owner.
2. Auth server redirects user to a page where Resource Owner gives consent (Either by explicit login if not already logged in).
3. Authorization Server validates authentication code and client credentials, issues access token.
4. Client access Protected Resources in Resource server using Access Token.
3. Implicit Grant Type
Implicit grant type is used when the client is running in any browser. Ex: Javascript application.
Workflow:
1. Client request for access token by submitting – client id, secret, response_type=”token” and the scope of access, to authorization server.
2. Authorization server redirects user to page where Resource owner gives consent.
3. Authorization server validates the approval and respond back with access token in the callback uri.
4. Client uses the access token to get access to any protected resources.
Note: Here access token is exposed and it is the least secured approach. Unless it is a client running in any browser, not suggested to choose this approach. Also refresh token is not issues in this case.
4. Client Credentials
This grant type is used when client itself is the resource owner and does not depend on any external server to authorize. In that case client id, secret will be to get access tokens.
Token Types
This is the random string generated by the authorization server.
Access Token: This token is used to retrive/access protected resources from resource server. Client needs to send this as a header parameter.
Suggested Header usage:
Authorization “Bearer tokenvalue”
Access token has a limited time scope.
Refresh Token: This token will be used by the clients when access token expires and client wants to renew this.
Issues with OAuth and the need of OpenID Connect
As we have discussed, authroization codes which are received by client in a redirect URI can be used to get access tokens assuming user has authorized. This leads to a security loop hole like this.
1. Lets say we have two sites A and B, both depends on Authorization Server C to authenticate users and login.
User clicks on login in site B, user authorized access and Auth server C issues authorization code back in a redirect URI. Somehow you stop this redirection flow.
Now user goes to Site A. Clicks on Login. Now, attacker might inject the authorization code received in earlier request(From site B) to site A redirection flow. So without actually going till Authorization server C and asking for user’s consent, access tokens are issues from Authorization server in site A.
Please note that the authorization code sent was not tied to any client. Hence Auth server cannot distinguish between which client had sent it.
2. At the end of OAuth authorization, client gets the access token which can be used to access the protected user resources. Now an attacker might use his access token on a different client and associate user session with his access token. Now there are chances that user uploads his private data to an attacker profile. Again here also access token received alone is not sufficient and does not guarantee that the same client has requested for it.
In order to overcome these problems, we could use a state parameter in the redirect URI. state parameter can have some value while client requesting auth code. Authorization server sends back this state parameter along with auth code in the redirect URI. That way client can make sure that this is the same auth code request.
Please note that OAuth is not an authentication framework, but an authorization framework. However people use it randomly as authentication agent.
OAuth gets you an access token and allows third party applications to access your personal data on behalf of you without sharing a password. User can choose to view/upload/update any of the personal data on behalf of the user by third party application using an access token. So it is purely exists in the context of authorization. OAuth does not try to prove that you are the right use who has requested. ie. Received access token does not carry any more information.
OpenID is an identity layer on top of OAuth authorization framework which gives some more information than just the access token like Oauth.
OpenID is an authentication protocol where in response it confirms that ‘who you are’ by sharing few more information about your profile. We can confirm that the requester and the new id token receive are of the same person. Moreover OpenID gives a standard interface irrespective of the different identity providers it can connect to. So we do not need to worry if there is an identity provider change in future. OpenID provides discovery of providers and gives a common interface to work with. Where as OAuth implementation is tied with a particular identity provider. Change in provider leads to more changes compared to OpenID implementation. Note that OpenID connect provides id_token which is a JWT, but you still need access_token to request OpenID provider for any user info.
