In the traditional client-server authentication model, if we are to provide a third party to access a restricted resource, resource owner must share its credentials.
This creates several problems and limitations, obviously :)
- Owner can’t revoke access if required as the others who using the credentials may effect.
- User will have full access to the data
- Third party must store the password with them to access the resources in future.
- User name password validation must be implemented on the server
OAuth
OAuth is a protocol that allows a user to grant a third party to access to a user’s protected resources without exposing credentials.
This approach decouples user and resource in to two separate entities so that a third party client can access the resource without reaching the resource owner(User) all the time. OAuth will exchange credentials for a access token to use in all the authorization flows.
Bringing in a token adds some additional advantages such as,
- decoupling user with resources
- limit access to the resources, may be not all the folders
- Expire the token if required so client will not have access
- Revoke the token if its hacked
Once the user approved with credentials, Authorization server will issue a token to the third party application to access the protected resource.
HOW
Let’s see how the OAuth flow is happening with Quora.com login.
If you are a new user you will be able signup using signup with Google option. When doing so you are authorizing Google to allow Quora to access you profile info. This authorizing is done using OAuth. But you don’t share your credentials with Quora.
There are mainly four actors involves OAuth.
- Resource Owner — User who wants to sign up using Quora, that’s me
- Client Application — This will be Quora
- Resource Server — This will be Gmail . Hosts the protected user accounts.
- Authorization Server — verifies the identity of the user then issues access tokens to the application.
OAuth 2 Protocol Flow
- The client requests authorization from the resource owner.
- The client receives an authorization grant, to access resource server.
- Client send the Athorization grant to authorization server to get a access token.
- The authorization server authenticates the client and validates
the authorization grant, and issues an access token. - The client presents the access token and requests for the protected resources.
- The resource server validates the access token, and serves the request.
Grant Types in OAuth 2
The OAuth specification describes four grants for acquiring an access token:
- Authorization code grant
- Implicit grant
- Resource owner credentials grant
- Client credentials grant
OAuth 2 Authorization Code Grant
Authorization code grant type exchanges authorization code for a token. This can be used with regular webpages as the code is hosted on a server and isn’t publicly exposed.
In this diagram resource owner will be browser and human user itself.
- User clicks login button in the client application.
- Client will redirect the user to the login and authorization prompt
- User authenticates through the auth server UI.
- Auth server will send a request back to the given redirect url with code and state parameters.
- The client will make another call with code, client is and secret to get the access token
- Client will make the final call with the access token to access the protected resource.
Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server , which in turn directs the resource owner back to the client with the authorization code. Because the resource owner only authenticates with the authorization server, the resource owner’s credentials are never shared with the client. Access Token is transmitted directly to the client.
OAuth 2 Implicit
This is same like Authorization code grant except Authorization server will issue a access token immediately without issuing a authorization token first.
This approach improve the responsiveness and efficiency but is less secure, optimized for clients implemented in a browser using a scripting language such as JavaScript.
When issuing an access token , the authorization server does not authenticate the client. — less secure.
OAuth 2 Resource owner password credentials
User will provide the user name and password to the client application to communicate with the authorization server and get the token.
Should only be used when there is a high degree of trust between the resource owner and the client.
Facebook mobile app will get your credentials directly and then pass to authorization server, is a example.
OAuth 2 Client credentials
The client credentials (or other forms of client authentication)
be used as an authorization grant.
This is used when the client is acting on its own behalf (the client is
also the resource owner). This used as a machine to machine authentication so user has no role to play. Typically used by clients to access resources about themselves rather than to access a user’s resources.
Let’s Learn some other terms relevant
Vulnerabilities
In the Implicit Grant, the access_token, application wants to maintain the session after the user closes the page, and it will be stored in the session cookie. The problem is server can’t verify the validity of the token.
Other things to note
The OAuth 2.0 protocol is not backward compatible with OAuth 1.0.
Token Types
1. Access tokens are credentials used to access protected resources.
The access token provides an abstraction layer, replacing different
authorization constructs with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server’s need to understand a wide range of authentication methods.
2. Authentication/Refresh tokens are credentials used to obtain access tokens, when the current access token becomes invalid or expires. Refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
Authentication Token vs Access Tokens
Access tokens are self contained token and hence they should be stored securely and if it go to wrong hands they will have the access with no issues.
Auth tokens verified against client credentials and hence hard to breach. Auth token says given client has approved access to given resources. But the resource server only accepts access token, so auth token shuould be exchanged to a access token.
Client Registration
The client application must first register with the authorization server associated with the resource server. At registration the client application is assigned a client ID and a client secret (password) by the authorization server. client SHALL provide its client redirection URIs
The authorization server issues the registered client a client
identifier — a unique string representing the registration
information provided by the client. The client identifier is not a
secret; it is exposed to the resource owner. This is unique to
the authorization server and is encoded using the
“application/x-www-form-urlencoded”.
Clients can be confidential or public based on maintainning the confidentialty of their credentials. Ex: web application executed on server vs a native application executes on a browsert agent.
Based on client type, public or confidential server authentication will be vary.
Endpoints
- Authorization endpoint
Used by the client via user-agent redirection to obtain authorization from the resource owner. Real interaction happens between Resource owner and Authentication server. Response Type parameter is used to set the grant type.
2. Token endpoint
Used by the client to exchange an authorization grant for an access token, typically with client authentication.
3. Redirection endpoint
Used by the authorization server to return authorization code to the client. This redirection endpoint should be provided when the client registration happens.
The redirection endpoint SHOULD require the use of TLS when the requested response type is “code” or “token”, But not mandate the use of TLS.
The authorization server MUST require the following clients to register their redirection endpoint:
- Public clients.
- Confidential clients utilizing the implicit grant type.
Ref:
https://www.javainuse.com/misc/oauth-interview-questions
https://0xn3va.gitbook.io/cheat-sheets/web-application/oauth-2.0-vulnerabilities