| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
Use this policy to authenticate a client by delegating the authentication to an OAuth2 provider. If this policy is applied, it is used to authenticate any request that does not contain credentials for any other authentication policies (such as API Key). The client is redirected to the OAuth provider to start the authentication flow. Once the flow completes, and the access token is obtained, the policy uses it to perform one or more requests to get information about the user, such as the ID and assigned role. Finally, a session cookie is returned to the client, and the client is redirected back to the requested URL. Subsequent requests authenticate based on the session cookie instead of repeating the OAuth flow. This implementation is based on the authorization code flow from Okta.
...
This policy might work with other authentication providers not listed above but has not been tested and verifiedwith other authentication providers not listed above but has not been tested and verified.
OAuth 2.0 Framework for Authorization Code Grant Type
The OAuth 2.0 Authorization Code grant flow is a way for an the client to request an authorization code from an authorization server with the involvement of a user. This flow is suitable for scenarios where the client application needs to access resources on behalf of a user.
The OAuth 2.0 Authorization Code flow enables a client application to access other services securely. This is done by authenticating the user's credentials without directly exposing the user's password to the client application. As the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client.
The client application requests an authorization code from the authorization server, which the user approves.
The client then exchanges the authorization code for an access token, which is used to access protected resources on the user's behalf.
OAuth Roles
Client: The client is an application that requests access to resources on another resource server. The client redirects the user to the authorization server for authentication and authorization.
Resource Owner (User): The user who owns the resources to which the client application is requesting access.
Authorization Server: The authorization server authenticates the user's identity and issues authorization codes and access tokens to the application once authorization is granted.
Mapping Out the Protocol Flow
...
Authorization Code Grant Flow
Client Registration: The application is registered with the Identity Provider such as Ping Identity, Okta, Github, Salesforce or Azure which issues a Client ID, Client Secret and Redirect URI. These credentials are used to authenticate the application to the Identity Provider.
Policy Configuration: Field settings of the policy for the API endpoint includes:
OpenID Discovery Document URL
Login URL
JWS Algorithm
Scopes
Access Token URL
Client ID and Client Secret
Redirect URI
Authorization Request: When the application needs to access resources on behalf of a user, it redirects the user to the Identity Provider's authorization endpoint, including its client ID and client secret where the authorization server sends the authorization code.
User Authentication and Authorization: The user authenticates with the Identity Provider and grants permission to the application to access their resources. If the user approves, the Identity Provider redirects the user back to the client application with an authorization code.
Token Request: The client application receives the authorization code and sends a request to the Identity Provider's token endpoint to exchange the authorization code for an access token.
Token Issuance: The Identity Provider validates the authorization code and the client's credentials. If valid, the Identity Provider issues an access token to the client application.
Resource Access: The client application uses the access token to access protected resources on behalf of the user. The access token is included in the authorization header of the HTTP request.
Policy Execution Order
The Generic OAuth2 policy executes after the other authentication policies, specifically those whose mechanisms are based on the client providing a token in the request, like the API Key or Callout Authenticator policies.
...
Parameter Name | Description | Default Value | Example | ||
|---|---|---|---|---|---|
Label | Required. The name for the API policy. | Generic OAuth2 | GitHub OAuth 2.0 Policy | ||
When this policy should be applied | An expression enabled field that determines the condition to be fulfilled for the API policy to execute. For example, if the value in this field is request.method == "POST", the API policy is executed only if the request method is a POST. | N/A | request.method == “POST” | ||
Use OpenID Connect | Select to use an OpenID Connect (OIDC) vendor as the 3rd-party IdP. | Deselected | Selected | ||
OpenID Discovery Document URL | Required. The OIDC discovery URL. | N/A | |||
Login URL* | Required. The login URL for the client. | N/A | |||
JWS Algorithm* | The algorithm used to generate the JSON Web Service token. You can find this in the Discovery Document URL to determine which algorithm is supported: Select one of the following algorithm types:
| RS256 | |||
Required Scopes | Required. The list of OAuth2 scopes required to get information about a user. See OAuth 2.0 Scopes for details. Click | N/A | N/A | ||
Scope | The name of the OAuth2 scope. | N/A | user token session | ||
Access Token URL | Required. The OAuth2 provider’s access token URL. The response from this token URL will be stored in $token and can be referenced in User Info URL below. | N/A | |||
Client ID | Required. The ID of the application registered with the OAuth2 provider. | N/A | |||
Client Secret | Required. The client secret for the application registered with the OAuth2 provider. | N/A | chocolatE | ||
Redirect URI | The URI of the Snaplex load-balancer appended with | N/A | |||
User Info URL #1-2 | These sections describe the HTTP GET requests this API policy should make to get information about a user.
User Info URL #2 is optional. | N/A | N/A | ||
Trust all certificates | Option to
| False/Not selected | N/A | ||
Target Path | The location to store the result of the request in the working object as a JSON-Path.
| N/A | $user | ||
URL | The destination for the request. | N/A | |||
Query Parameters | The query parameters (name and value) to add into the URL. | N/A | N/A | ||
Headers | The headers (name and value) to include in the request. | N/A | Authorization | ||
Extract User Info | Required. Specifies how to extract information about the user from the working object. | N/A | N/A | ||
User ID Expression | Required. An expression that returns a string to be used as the user ID. | N/A | $user.email | ||
Roles Expression | Required. An expression that returns the list of roles this user is in. | N/A | $user.groups.map(group => group.name) | ||
Session: Time-To-Live in Seconds | Required. The number of seconds for which the session is active. | 86400 | 90000 | ||
OAuth State: Time-To-Live in Seconds | Required. The number of seconds for which the Oauth state is active. | 300 | 1000 | ||
Status | Specifies whether the API policy is enabled or disabled. | Enabled | Disabled |
to add scopes....