Dualog Access - Supported Grant Types and Use

INTRODUCTION

The OAuth 2.0 Authorization Framework supports several different grant types or ways of retrieving the Access Token. Which one to use depends mostly on application type, but other parameters weigh in as well, like the level of trust for the client, or the experience you want your users to have.

Version 1 of Dualog Access only supports the Resource Owner Password Flow (Section 4.7). Other grant types will be added in later versions.

List of Supported Grant Types:

1. Authorization Code Flow
2. PKCE
3. Implicit Flow with Form Post
4. Hybrid Flow
5. Client Credentials Flow
6. Device Authorization Flow
7. Resource Owner Password Flow

• AUTHORIZATION CODE FLOW
  

For server-side applications where the source code is not publicly exposed, the Authorisation Code Flow can be used. An Authorization Code is exchanged for a token.

As the application’s Client Secret is passed, the application must be server-side. The Client Secret must be kept secure – stored in the client.

• PKCE
  

PKCE (Authorisation Code Flow with Proof Key for Code Exchange) is an extension to the Authorization Code flow to prevent attacks and to be able to securely perform the OAuth exchange from public clients.

It was originally designed to protect mobile apps, but its ability to prevent authorization code injection makes it useful for every OAuth client, even web apps that use a client secret.

When public clients (e.g., native and single-page applications) request Access Tokens, some additional security concerns are posed not mitigated by the Authorization Code Flow alone:

• Native Apps cannot securely store a Client's Secret. Decompiling the app will reveal the Client's Secret, bound to the app and equal for all users and devices.
• Single-Page Apps cannot securely store a Client's Secret as the source code is available to the browser.

OAuth 2.0 provides a version of the Authorization Code Flow making use of a Proof Key for Code Exchange.

The PKCE-enhanced Authorization Code Flow introduces a secret created by the calling application, to be verified by the authorization server (Code Verifier). In addition, the calling app creates a transform value of the Code Verifier (Code Challenge) sending this over HTTPS to retrieve an Authorization Code.

This way, a malicious attacker can only intercept the Authorization Code, and they cannot exchange it for a token without the Code Verifier.

• IMPLICIT FLOW WITH FORM POST
  

The Implicit Flow is intended for Public Clients or applications which are unable to securely store Client Secrets. This is no longer considered a best practice for requesting Access Tokens. But when used with Form Post response mode, it offers a streamlined workflow if the application needs only an ID token to perform user authentication.

Implicit Flow with Form Post applies to traditional web apps as opposed to Single-Page Applications. ID tokens are obtained, as opposed to accessing tokens, which have a completely different intended use. The flow uses POST instead of placing tokens in URL fragments (as with SPAs) which can expose token bits to browser history attacks, redirect headers, etc.

• HYBRID FLOW

Applications able to securely store Client Secrets may benefit from the use of the Hybrid Flow. It combines features of the Authorization Code Flow and Implicit Flow with Form Post to allow your application to have immediate access to an ID token while still providing for secure and safe retrieval of access and refresh tokens.

This can be useful in situations where your application needs to immediately access information about the user but must perform some processing before gaining access to protected resources for an extended period.

• CLIENT CREDENTIALS FLOW

With machine-to-machine (M2M) applications, the system authenticates and authorizes the app rather than a user. For this scenario, typical authentication schemes like username + password do not make sense. Instead, M2M apps use the Client Credentials Flow.

• DEVICE AUTHORISATION FLOW
  

With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a link on their computer or smartphone and authorize the device.

This avoids a poor user experience for devices that do not have an easy way to enter text. To do this, device apps use the Device Authorization Flow. For use with mobile/native applications

• RESOURCE OWNER PASSWORD FLOW

Highly trusted applications can use the Resource Owner Password Flow, which requests that users provide credentials (username and password).

The Resource Owner Password Flow should only be used when redirect-based flows (like the Authorization Code Flow) cannot be used.