OAUTH
OAuth is security protocol, which is used to grant authorization access resources.
From the wiki, "OAuth is an open standard for authorization, commonly used as a way for Internet users to authorize websites or applications to access their information on other websites but without giving them the passwords".
The current version of OAuth at the time of writing this book is OAuth2.0
Roles in OAuth2.0:
There are four roles in OAuth2.0:
- Authorization Server
- Resource Server
- Client
- Resource Owner
Let us take a look at each of these.
1. Authorization Server:
Authorization Server is the server which performs the following actions:
- Authenticates the client
- Issues a time limited token
- Validates the token (including checking the token for expiry)
2. Resource Server:
Resource server is the server which hosts the Resource in question, and provides secure access to the resource. (By validating the token provided in the access request)
3. Resource Owner:
Resource Owner is the user who authorizes the access to its account.
4. Client:
Client is the user/application which requests access to the resource.
Example Use case:
- Let us say a user accesses an ecommerce application, 'BuyMe'. The application 'BuyMe', presents a login option to sign in using Google/Facebook Account.
- The user selects 'Login using Google Account'.
- The user is redirected to Google Login page.
- When the user logs into Google Account, the user is asked whether he/she would like to allow 'BuyMe' application to access few details from his/her Google Account.
- Upon agreeing to grant access, the user would be redirected to the BuyMe application.
There are few things going on behind the scenes in the above use case:
1. Provisioning of the Client application with the Authenticator:
The BuyMe application would have registered itself initially with the Google Application for the purpose of Authentication. During registration, the Client Application would have provided the Authenticator (Google App) with a redirect URI and, the Authenticator would have provided the BuyMe application with a Client Id and a secret. This is a onetime process also known as provisioning.
2. Authentication Code:
The Authenticator (Google App) would append an Authentication Code to the URI while redirecting to the client application. The client application would request for a token from the Authenticator (Google App), by sending the client ID, password and the authentication code. The authenticator would validate these details, and if valid, would send back a token. The client application would send the token in all the further requests while accessing data from the Google application.
Grant Types:
OAUTH 2.0 specifies four types of Grants:
- Authorization Code
- Implicit
- Resource Owner Password Credentials
- Client Credentials
1. Authorization Code
The above use case illustrates 'Authorization Code' type Grant.
2. Implicit
In the Implicit type Grant, the Authorization code is not returned. Instead, the token is immediately returned to the client application.
3. Resource Owner Password Credentials
In 'Resource Owner Password Credentials' grant, the client application maintains the username/password of the Authenticator application and the client application would use these credentials to send them over to the Authenticator.
4. Client Credentials
In the 'Client Credentials', the client is requesting access to protected resources under its control (i.e. there is no third party).
Why is OAuth important in the cloud?
In cloud environment, if Microservices Architecture is embraced, then we need a way to secure all the individual services. OAuth is a popular choice for securing these services, with each service acting as a 'Resource Server'. The Auth Server could be a home grown server, which could be built to authenticate the user and provide a time limited token.
Also, with a lot of modern B2C applications allowing multiple login options (like login via Facebook, Google etc.), OAuth protocol, invariably finds an important role to play.