Skip to content
Cloudflare Docs

Generic OIDC

Cloudflare Access has a generic OpenID Connect (OIDC) connector to help you integrate IdPs not already set in Access.

Set up a generic OIDC

  1. Visit your identity provider and create a client/app.

  2. When creating a client/app, your IdP may request an authorized redirect URI. Enter the following URL:

    https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback

    You can find your team name in Zero Trust under Settings > Custom Pages.

  3. Copy the content of these fields:

    • Client ID
    • Client secret
    • Auth URL: The authorization_endpoint URL of your IdP
    • Token URL: The token_endpoint URL of your IdP
    • Certificate URL: The jwks_uri endpoint of your IdP to allow the IdP keys to sign the tokens

    You can find these values on your identity provider's OIDC discovery endpoint. Some providers call this the "well-known URL".

  4. In Zero Trust ↗, go to Settings > Authentication.

  5. Under Login methods, select Add new.

  6. Choose OpenID Connect..

  7. Name your identity provider and fill in the required fields with the information obtained in Step 3.

  8. (Optional) Enable Proof of Key Exchange (PKCE) ↗ if the protocol is supported by your IdP. PKCE will be performed on all login attempts.

  9. (Optional) To enable SCIM, refer to Synchronize users and groups.

  10. (Optional) Under Optional configurations, enter custom OIDC claims that you wish to add to users' identity. This information will be available in the user identity endpoint.

  11. Select Save.

To test that your connection is working, go to Authentication > Login methods and select Test next to the login method you want to test. On success, a confirmation screen displays.

Synchronize users and groups

The generic OIDC integration allows you to synchronize user groups and automatically deprovision users using SCIM.

Prerequisites

Your identity provider must support SCIM version 2.0.

1. Enable SCIM in Zero Trust

  1. In Zero Trust ↗, go to Settings > Authentication.

  2. Find the IdP integration and select Edit.

  3. Turn on Enable SCIM.

  4. (Optional) Configure the following settings:

  • Enable user deprovisioning: Revoke a user's active session when they are removed from the SCIM application in IdP. This will invalidate all active Access sessions and prompt for reauthentication for any WARP session policies.
  • Remove user seat on deprovision: Remove a user's seat from your Zero Trust account when they are removed from the SCIM application in IdP.
  • SCIM identity update behavior: Choose what happens in Zero Trust when the user's identity updates in IdP.
    • Automatic identity updates: Automatically update the User Registry identity when IdP sends an updated identity or group membership through SCIM. This identity is used for Gateway policies and WARP device profiles; Access will read the user's updated identity when they reauthenticate.
    • Group membership change reauthentication: Revoke a user's active session when their group membership changes in IdP. This will invalidate all active Access sessions and prompt for reauthentication for any WARP session policies. Access will read the user's updated group membership when they reauthenticate.
    • No action: Update the user's identity the next time they reauthenticate to Access or WARP.

  1. Select Save.

  2. Copy the SCIM Endpoint and SCIM Secret. You will need to enter these values into IdP.

The SCIM secret never expires, but you can manually regenerate the secret at any time.

2. Configure SCIM in the IdP

Setup instructions vary depending on the identity provider. In your identity provider, you will either need to edit the original SSO application or create a new SCIM application. Refer to your identity provider's documentation for more details. For example instructions, refer to our Okta or Jumpcloud guides.

IdP groups

If you would like to build policies based on IdP groups:

  • Ensure that your IdP sends a groups field. The naming must match exactly (case insensitive). All other values will be sent as a OIDC claim.
  • If your IdP requires creating a new SCIM application, ensure that the groups in the SCIM application match the groups in the original SSO application. Because SCIM group membership updates will overwrite any groups in a user's identity, assigning the same groups to each app ensures consistent policy evaluation.

3. Verify SCIM provisioning

To check if a user's identity was updated in Zero Trust, view their User Registry identity.

Optional configurations

OIDC claims

OIDC integrations support the use of custom OIDC claims. Custom OIDC claims can be referenced in Access policies, offering a means to control user access based on these specific attributes. Custom OIDC claims are not currently supported in Gateway policies.

Email claim

You can specify a custom Email claim name that Access will use to identify user emails. This is useful if your IdP does not return the standard email claim in the OIDC ID token.

Multi-record OIDC claims

Cloudflare Access extends support for multi-record OIDC claims. These claims are parsed out and can be individually referenced in policies. This feature enables granular access control and precise user authorization in applications.

Cloudflare Access does not support partial OIDC claim value references or OIDC scopes.

Example API Configuration

{
  "config": {
    "client_id": "<your client id>",
    "client_secret": "<your client secret>",
    "auth_url": "https://accounts.google.com/o/oauth2/auth",
    "token_url": "https://accounts.google.com/o/oauth2/token",
    "certs_url": "https://www.googleapis.com/oauth2/v3/certs",
    "scopes": ["openid", "email", "profile"]
  },
  "type": "oidc",
  "name": "Generic Google"
}
Cloudflare DashboardDiscordCommunityLearning CenterSupport Portal
Cookie Settings