Authentication Flows

There are many types of authentication flows (flows used to gain authentication) each supported by different web standards such as OAuth and OpenIdConnect (OIDC). These web standards describe how authentication and authorization (depends on the grant) can be achieved between resource owner (user) and the client application’s user data.

There are many factors influencing the type of flow and grant type to use for a given application including the type of application, when the application built (protocol may have been available when it was developed) and whether applications are restricted to certain technology stacks.

We will be covering these following authentication flows:

Resource Owner Flow

This type of AF is not commonly used in enterprise applications due to the limited benefits this flow provides. Resource Owner Flow (ROF) does not provide the desired abilities such as IdP delegation, single sign-on, etc…

ROF is “self-contained” since the application handles the authentication, issues authentication token, and verifies the authenticity of the token within the same application. ROF applications tend to be bespoke with the purpose of authenticating using auth tokens.

Resource Owner Flow Credentials Grant (source). The resource owner provides user credentials to client application. The client application initiates request to get access token if user is authenticated. Subsequent request for refresh token is optional.

Demo: resource owner grant example

The flow starts by the user being presented with a login page requesting credentials. These credentials are passed onto the authentication server. Typically the authentication server should be separate from the application server (but does not have to be).

POST /token HTTP/1.1   Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8

grant_type=password&username=johndoe&password=A3ddj3w 
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
  }

A subsequent request to the server is validated through a bearer token. The token must be attached to an all requests headers.

source – resource owner flow
source – example of resource owner flow implementation

Client Credential Flow

Such Client Credential grant should only be used for Confidential Client applications since it requires the client to store a Client Id and Client Secret. The access token is directly requested using the stored credentials.

Client Credential flow, credentials is stored in the client application and used to request access token for resource request.

Implicit Flow

The implicit grant is a simplified authorization code flow optimized for public clients. In the Implicit grant flow, the client has issued an access token directly after authorization. The grant type is implicit because no intermediate credentials are issued (such as an authorization code which is later used to obtain an access token).

In the Implicit grant, the authorization server does not authenticate the client when issuing access tokens. Instead of implicit grant relies on the resource owner (browser) to handle the redirection from the authorization server ( the access token is encoded into the redirection URI registered with the Authorization Server). (source)

Implicit grant flow steps. Resource Owner redirects user for authorization. Once authorized, the user is granted access_token and redirected back to resource owner which can be used to gain access to Web Client resources.

Implicit grant flow is different from the Authorization code grant flow because the access token is sent back to the client application without the need for an authorization request token. This flow type suitable for client-side web applications (SAP) that need temporary access (a few hours) to the API data. (source)

Authorization Grant Flow

The authorization code grant type is used to obtain both access tokens and refresh tokens. The Authorization grant uses redirection-based flow, the client application must be capable of interacting with the resource owner’s user-agent (web browser) and capable of receiving incoming requests (via redirection) from the authorization server. Generally, this is the preferred flow for confidential client applications such as API servers. (source)

Authorization code grant flow starts with the user requesting authorized resources. The user is presented with IdP login. Once the user is authenticated, the authorization code is redirected to the user agent (web browser). The user agent request resources using the authorization code. The client application (API) requests an access token using the authorization code.

source – Authorization code grant flow in detail
source -OAuth Authorization code flow

OpenIdConnect Flows

OAuth and OpenIdConnect

OAuth is an opensource web standard that defines various grant type protocols. Main supported grant types:
1. Client Credential Grant
2. Resource Owner Password Credential Grant
3. Implicit Grant
4. Authorization Code Grant

OpenIdConnect (OIDC) is built on top of OAuth grants and extends support to additional flow types. In addition, OIDC has support for additional endpoints not found in OAuth for example:

– Authorization endpoint used to issue access tokens and redirection on authentication of a user.
– The token endpoint, used for programmatic requested endpoints. (no redirection)

OIDC supported flows build on top of OAuth grants:
1. Authorization Code Flow
2. Implicit Flow
3. Hybrid Flow

source – oauth2 and OIDC grant types

One Reply to “Authentication Flows”

  1. Hello, nice work. I really appeaciate the data you are providing through your website, i have alwasy find it helpful. Keep up the amazing work.

Leave a Reply

Your email address will not be published. Required fields are marked *