OAuth 2.0 Flow

OAuth 2.0 is a protocol that allows a user to grant limited access to their resources /information in one site, while authenticating on another. Typically this is done without having to expose their credentials.

Overview

OAuth 2.0 covers different ways a client application can obtain authorization to access the resources stored on the resource server. Here we will show you the most common, and most secure use case: A client web application requesting access to resources in another web application.

  1. The Application (Client) asks for authorization from the Resource Owner in order to access the resources.

  2. Provided that the Resource Owner authorizes this access, the Application receives an Authorization Grant. This is a credential representing the Resource Owner's authorization.

  3. The Application requests an Access Token by authenticating with the Authorization Server and giving the Authorization Grant.

  4. 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.

  5. 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.

OAuth 2.0 Roles:

OAuth 2.0 defines the following roles for users and applications:

These roles are illustrated in this diagram:

1. Resource Owner: The resource owner is the person or application that owns the data that is to be shared. For instance, you are the resource owner for your data/account with Facebook. Though a resource owner is a person, it could also be an application.

2. Resource Server:This is the hosting resource server. For instance, Facebook or Google is a resource server.

3. Client Application:The client application is the application requesting access to the resources stored on the resource server. The resources are owned by the resource owner.

4. Authorization Server: The authorization server is the server authorizing the client app to access the resources of the resource owner.

OAuth 2.0 Client Types

OAuth 2.0 defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):

1. Public
2. Confidential

  1. Public: Clients incapable of maintaining the confidentiality of their credentials nor capable of secure client authentication using any other means. (e.g., A client, ie, an installed native application or a web browser-based application which execute on a device used by resource owner).

  2. Confidential: Clients capable of maintaining the confidentiality of their credentials or capable of securing client authentication using other means. (e.g., client implemented on a secure server with restricted access to the client credentials).

Here a list of commonly used types of client applications:

OAuth 2.0 Grant Types

In OAuth 2.0, the term “grant type” refers to the way an application gets an access token. OAuth 2.0 defines several grant types, including the authorization code flow. OAuth 2.0 extensions can also define new grant types.

Each grant type is optimized for a particular use case, whether that’s a web app, a native app, a device without the ability to launch a web browser, or server-to-server applications.

While creating apps you can choose the below mentioned pre-defined “Grant Types”.

Grant Types More Information
Implicit Can be used by public clients, where the access token is returned immediately without an extra authorization code exchange step
Authorization Code Initiated by redirecting the user in the web browser to the cidaas /authz endpoint.
Authorization Code Flow PKCE In addition to "Authorization Code Flow", the client embeds a code_verifier/secret that only Authorization server can recognize
Client Credentials Use when applications request an access token to access their own resources, not on behalf of a user.
Password This is used when the application exchanges the user’s username and password for an access token.
Refresh Token To be used by clients to exchange a refresh token for an access token when the access token has expired.
Device Flow To be used by clients to exchange a refresh token for an access token when the access token has expired.

results matching ""

    No results matching ""