Generic OAuth2
- John Brinckwirth
- Rachana Mannath
- Ankur Parekh
- 1 Overview
- 2 Settings
- 3 Examples of Configuring the Generic OAuth2 API Policy with OIDC Providers
- 3.1 Google IdP Application Field Mappings
- 3.1.1 Prerequisites
- 3.1.2 Workflow
- 3.1.3 Example Settings
- 3.1 Google IdP Application Field Mappings
- 4 Azure IdP Application Field Mappings
- 4.1 Microsoft Entra ID
- 4.1.1 Prerequisites
- 4.1.2 Workflow
- 4.1.3 Example Settings
- 4.2 AD B2C Application
- 4.2.1 Prerequisites
- 4.2.2 Workflow
- 4.2.3 Example Settings
- 4.1 Microsoft Entra ID
- 5 Session Management
- 6 Related Content
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.
Starting in the October 2023 release, SnapLogic supports the implementation of OpenID. You can now use your OpenID Connect provider for the authentication controls in your Genric OAuth2 API policy.
The Generic OAuth2 API Policy also supports OAuth 1.0.
Policy Requirements
All Authentication policies require the Authorize By Role policy to authenticate the API caller correctly. For example, you can configure this policy to add the role “admin” to the client and then configure the Authorize By Role policy to authorize users with that role.
Users must enable cookies in their browser for this policy to work with OAuth providers.
Verified Providers
SnapLogic verified the following authentication providers for this policy:
This policy might work with 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.