What Is OAuth 2.0?
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group
OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and DigitalOcean. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices.
OAuth Is Needed For?
- Federated Identity : — Allowing users to log in to an application with another account.
- Delegated Authority : — Allowing another service to access resources on another service on behalf of the user.
OAuth Roles
- Resource Owner
- Client
- Resource Server
- Authorization Server
We will detail each role in the following subsections.
Resource Owner: User
The resource owner is the user who authorizes an application to access their account. The application’s access to the user’s account is limited to the “scope” of the authorization granted (e.g. read or write access).
Client: Application
The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.
Resource Server
The server hosting the protected resources. This is the API you want to access.A Resource Server (can be the same as the Authorization Server or a separate application) serves resources that are protected by the OAuth2 token. Spring OAuth provides a Spring Security authentication filter that implements this protection.
Authorization Server
The server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0.OAuth 2 Authorization Server is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and DigitalOcean.
Before diving deeper into OAuth 2.0, it is important to understand what the following keywords mean.
Authentication — validating if the person is who he says he is.
Authorization — what actions a person is allowed to perform when he/she has been authenticated.
OAuth 2.0 Protocol Flow
- The Application (Client) asks for authorization from the Resource Owner in order to access the resources.
- Provided that the Resource Owner authorizes this access, the Application receives an Authorization Grant. This is a credential representing the Resource Owner’s authorization.
- The Application requests an Access Token by authenticating with the Authorization Server and giving the Authorization Grant.
- Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application.
- The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token.
- Provided that the Access Token is valid, the Resource Server serves the Application’s request.
1. Authorization Grant Type
The OAuth 2.0 Authorization Framework specification defines four flows to get an Access Token. These flows are called grant types. Deciding which one is suited for your case depends mostly on the type of your application.
1.Authorization Code: used by Web Apps executing on a server. This is also used by mobile apps, using the Proof Key for Code Exchange (PKCE) technique.
2.Implicit: used by JavaScript-centric apps (Single Page Applications) executing on the user’s browser.
3.Resource Owner Password Credentials: used by trusted apps.
4.Client Credentials: used for machine to machine communication.
The specification also provides an extensibility mechanism for defining additional types.
2. Implicit Grant Type
The Implicit Grant Type is a way for a single-page JavaScript app to get an access token without an intermediate code exchange step. It was originally created for use by JavaScript apps (which don’t have a way to safely store secrets) but is only recommended in specific situations.
The implicit grant type is used for mobile apps and web applications (i.e. applications that run in a web browser), where the client secret confidentiality is not guaranteed. The implicit grant type is also a redirection-based flow but the access token is given to the user-agent to forward to the application, so it may be exposed to the user and other applications on the user’s device. Also, this flow does not authenticate the identity of the application, and relies on the redirect URI (that was registered with the service) to serve this purpose. The implicit grant type does not support refresh tokens.
The implicit grant flow basically works as follows: the user is asked to authorize the application, then the authorization server passes the access token back to the user-agent, which passes it to the application.
3.Client Credentials Grant Type
The client credentials grant type provides an application a way to access its own service account. Examples of when this might be useful include if an application wants to update its registered description or redirect URI, or access other data stored in its service account via the API.
4.Password Credentials Grant Type
The resource owner password (or “password”) grant type is mostly used in cases where the app is highly trusted. In this configuration, the user provides their resource server credentials (username/password) to the client app, which sends them in an access token request. An identity server validates the credentials, and if they are valid, Edge proceeds to mint an access token and returns it to the app.
OAuth Endpoints
OAuth 2.0 utilizes two endpoints: the Authorization endpoint and the Token endpoint.
1.Redirect Endpoint
The redirect endpoint is the endpoint in the client application where the resource owner is redirected to, after having granted authorization at the authorization endpoint.This is provided by the Client Application to the service provider. The service provider will send the access tokens etc to this endpoint.
2.Token Endpoint
he Token endpoint is used by the application in order to get an Access Tokens or a Refresh Tokens. It is used by all grant types, except for Implicit grant (since an Access Token is issued directly). In the Authorization Code grant, the application exchanges the authorization code it got from the Authorization endpoint for an Access Token.In the Client Credentials and Resource Owner Password Credentials grants, the application authenticates using a set of credentials and then gets an Access Token.
3.Authorization Endpoint
The Authorization endpoint is used to interact with the resource owner and get the authorization to access the protected resource. To better understand this, imagine that you want to log in to a service using your Google account. First, the service will redirect you to Google in order to authenticate (if you are not already logged in) and then you will get a consent screen, where you will be asked to authorize the service to access some of your data (protected resources), for example your email address and your list of contacts.
The request parameters of the Authorization endpoint are:
- response_type: Tells the authorization server which grant to execute. Refer to the How Response Type Works paragraph for details.
- client_id: The id of the application that asks for authorization.
- redirect_uri: Holds a URL. A successful response from this endpoint results in a redirect to this URL.
- scope: A space-delimited list of permissions that the application requires.
- state: An opaque value, used for security purposes. If this request parameter is set in the request, then it is returned to the application as part of the redirect_uri
