API Management versions 7.5.X and 7.6.X have reached end of support in November 2020.
Check out the latest version of the documentation.

API Gateway OAuth 2.0 authentication flows

API Gateway can use the OAuth 2.0 protocol for authentication and authorization. API Gateway can act as an OAuth 2.0 authorization server and supports several OAuth 2.0 flows that cover common web server, JavaScript, device, installed application, and server-to-server scenarios. This section describes each of the supported OAuth 2.0 flows in detail, and shows how to run sample scripts demonstrating the flows.

The API Gateway supports the following authentication flows:

  • Authorization code grant (or web server) flow – The web server authentication flow is used by applications that are hosted on a secure server. A critical aspect of the web server flow is that the server must be able to protect the issued client application's secret.
  • Implicit grant (or user agent) flow – The user agent authentication flow is used by client applications residing on the user's device. This can be implemented in a browser using a scripting language such as JavaScript or Flash. These client applications cannot keep the client application secret confidential.
  • Resource owner password credentials flow – This user name and password authentication flow can be used when the client application already has the resource owner's credentials.
  • Client credentials grant flow – This user name and password flow is used when the client application needs to directly access its own resources on the resource server. Only the client application's credentials are used in this flow. The resource owner's credentials are not required.
  • JWT flow – This flow is similar to OAuth 2.0 client credentials. A JSON Web Token (JWT) is a JSON-based security token encoding that enables identity and security information to be shared across security domains.
  • Refresh token – After the client application has been authorized for access, it can use a refresh token to get a new access token. This is only done after the consumer already has received an access token using the authorization code grant or resource owner password credentials flow.
  • Revoke token flow – A revoke token request causes the removal of the client application permissions associated with the particular token to access the end-user's protected resources.
  • Token information service flow – The OAuth token information service responds to requests for information on a specified OAuth 2.0 access token.
  • SAML assertion – The OAuth 2.0 Access Token using SAML Assertion filter enables an OAuth client to request an access token using a SAML assertion. This flow is used when a client wishes to utilize an existing trust relationship, expressed through the semantics of the SAML assertion, without a direct user approval step at the authorization server.

For more information on running sample scripts to demonstrate the flows, see Run the sample scripts.

Related Links