An Authorisation Grant is the credetial representation the Resource Owner's authorisation of the Client's access to its protected resources. The specifications define four Grant types, described below.
- Authorisation Code
- Resource Owner password Credentials
- Client Credentials
The Authorisation code is obtained by using an Authorisation server as an intermediary between the client and the resource owner. Instead of requesting authorisation directly from the resource owner, the client directs the resource owner, via the user-agent, to the authorisation server. The Authorisation server redirects the resource owner, via the user-agent, back to the client with an Authorisation code. This authorisation code is then used by the client to authenticate itself and fetch Access tokens. Access tokens are, finally, used by the client to access the protected resources ( residing on Resource server) of the resource owner.
Before directly the resource owner back to the client with the authorisation code, the Authorisation server authenticates the resource owner ( through an Authorisation server and Resource server interaction ) and obtains authorisation. Because resource owner authenticates with authorisation only, hence the resource owner's credentials are hidden from the client.
The Authorisation code provides important security benefits, such as
- Ability to authenticate the Client
- Transmission of Access token directly to the Client, without passing it through the Resource owner's user-agent. Hence keeping the access token within the scope of the Client, without exposing it to the user or the user-agent.
Implicit Grant is a simplified Authorisation code workflow. Here the client is issued the Access tokens, just after the Resources owner's authentication. The access token is thus returned, when the user-agent is redirected to the Client.
This implies that
- No Authorisation Code is required by the Client to obtain Access tokens. They are issued directly on redirection, immediately after resource owner authentication.
- Authorisation server does not Authenticate the Client
- Access tokens issued are now visible to the user-agent. This can pose some security loops
Because of the above three restrictions, this type authorisation grant workflow is optimised for Clients that are implemented in the Browser
Resource Owner Password Credentials
The Resource Owner's Login Credentials i.e username and password can be used directly as an authorisation grant, by the Client, to obtain Access Tokens. This workflow should be used only when there is high degree of trust be the resource owner and the client. e.g client is a part of highly privileged application, and used privately by the resource owner.
This grant type should eliminate the need for the client to store the resource owner's credentials for future use, instead should use long term access tokens or refresh tokens.
The Client Credentials, or any form of Client Authentication, can be as an Authorisation grant to obtain Access tokens. Here, the authorisation scope is limited to the protected resources, controlled by the client. i.e when the client is itself the owner of the protected resources. This workflow is also valid when the proctected are of the nature that they can be publicly accessed by multiple client, i.e when the proctected resources are now owned by any user in particluar.