Skip to main content

Appendix C - Authorisation Code Grant, Implicit and Resource Owner Password Credentials Flows

Status

Ready for review

This appendix captures:

  • The Oauth2 Authorisation Code Flow (without PKCE) - it is here for information purposes
  • The Implicit and Resource Owner Password Credential flow. Both of these flows SHOULD NOT be used but this has been included for information purposes

Authorisation code grant flow type)​

The end user on a web based service receives a request to access a protected resource. To access the resource the following flow occurs.

plantuml

Implicit OAuth 2​

Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants

The implicit grant type was developed for public client that run as a native (Javascript),Single Page App (SPA) or as a mobile application.

As the application is running directly in the user's mobile device or browser it is regarded as less secure than the Authorisation code flow where the application runs on a server

Only the Access token (never the Refresh Token) is transmitted from the Authorisation Server to the client.

The API Consumer works directly with the OAuth 2 / Open ID Connect server and get the token directly from the authorisation endpoint.

considering the security impact of cross-site scripting (XSS) attacks that could leak the access token to other systems, and implement Cross-Origin Resource Sharing (CORS) to make OAuth 2.0 requests to different domains. Due to the security implications of this flow if used it MUST only be used for PUBLIC APIS and MUST use PKCE flow whenever possible.

plantuml

Resource Owner Password Credentials​

This MUST NOT be used.

Resource Owner Password Credentials flow uses the user's credential (username and password) and password to obtain the token.

Because the resource owner shares their credentials with the client, this flow is deemed the most insecure of the OAuth 2.0 flows. The resource owner’s credentials can potentially be leaked or abused by the client application, and the resource owner has no control over the authorisation process.

The client should never store the credentials of the Resource Owner

It is a simple flow that only requires one call and provides both access and refresh tokens, and like the code flow it has to have a clientID and secret.

This in NOT a recommended flow and in fact is dropped in Oauth 2.1 and is only included here for completeness

The example for which is was developed was where the client and the resource provider are owned by the same company and used for Customer Authorisation pattern if Authorisation Code grant flow can’t be used.

COULD be used for Internal Use Only pattern to secure Internal APIs that use Active Directory Groups / Kerberos for authorisation and authentication if Authorisation Code grant flow is not available

plantuml