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

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

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

   You can find your team name inCloudflare One ↗ underSettings >Team name and domain >Team name.

3. Copy the content of these fields:

   • Client ID
   • Client secret
   • Auth URL: Theauthorization_endpoint URL of your IdP
   • Token URL: Thetoken_endpoint URL of your IdP
   • Certificate URL: Thejwks_uri endpoint of your IdP to allow the IdP keys to sign the tokens

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

curl"https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/identity_providers"\
--requestPOST\
--header"Authorization: Bearer$CLOUDFLARE_API_TOKEN"\
--json'{
"name": "Generic OIDC example",
"type": "oidc",
"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",
"pkce_enabled": false,
"email_claim_name": "email",
"claims": [
"employeeID",
"groups"
],
"scopes": [
"openid",
"email",
"profile"
]
}
}'

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

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

Your identity provider must support SCIM version 2.0.

1. InCloudflare One ↗, go toIntegrations >Identity providers.

2. Find the IdP integration and selectEdit.

3. Turn onEnable 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 anyWARP session policies.
• Remove user seat on deprovision:Remove a user's seat from your Cloudflare One account when they are removed from the SCIM application in IdP.
• SCIM identity update behavior: Choose what happens in Cloudflare One when the user's identity updates in IdP.
  • Automatic identity updates: Automatically update theUser Registry identity when IdP sends an updated identity or group membership through SCIM. This identity is used for Gateway policies and WARPdevice 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 anyWARP 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.

5. SelectRegenerate Secret. Copy theSCIM Endpoint andSCIM Secret. You will need to enter these values into IdP.

6. SelectSave.

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

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

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

• Ensure that your IdP sends agroups 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 theoriginal 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.

To check if user identities were updated in Cloudflare One, view yourSCIM provisioning logs.

All OIDC IdP integrations support the use of custom OIDC claims. Once configured, Access will add the claims to theAccess JWT for consumption by your origin services. You can reference the custom OIDC claims inAccess policies, offering a means to control user access to applications based on custom identity attributes. Custom OIDC claims are not currently supported in Gateway policies.

To add a custom OIDC claim to an IdP integration:

1. In your identity provider, ensure that the custom claim is included in your OIDC ID token.

2. InCloudflare One ↗, go toIntegrations >Identity providers.

3. UnderYour identity providers, find your identity provider and selectEdit.

4. UnderOIDC Claims, enter the name of your custom claim (for example,oid).

5. SelectSave.

6. SelectTest and verify that the custom claim appears inoidc_fields. For example,

   "oidc_fields":{
   "oid":"54eb1ed2-7150-44e6-bbe4-ead24c132fd4"
   },

You can now build an Access policy for the custom claim using theOIDC Claim orIdP OIDC Claim selector. The custom claim will also be passed to origins behind Access in aJWT.

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

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.

Cloudflare supports the following algorithms for verifying generic OIDC tokens:

• RS512
• RS256
• PS512
• ES256
• ES384
• ES512