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 (web server) – 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 (user agent) – The user agent authentication flow is used by client applications residing in the user's device. This could 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 – This user name and password authentication flow can be used when the client application already has the resource owner's credentials.
• Client credentials grant – 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 – 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 – 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 – 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.