If you're experiencing empty OIDC claims in Ory, there are several potential causes and debugging approaches you can take: ## Common Causes for Missing OIDC Claims 1. Missing OpenID Scope: You might have forgotten to request the

openid

scope when initiating the flow. As mentioned in the [Hydra debugging documentation](https://www.ory.sh/docs/hydra/debug), this is a common reason for missing ID tokens and claims. 2. Incorrect Jsonnet Mapping: Your data mapping configuration might be incorrect, causing the claims from the provider not to be properly mapped to your identity schema. 3. Incomplete OAuth2 Flow: If the previous OIDC flow for the same client didn't complete properly, it can cause issues with subsequent attempts, as seen in [this GitHub issue](https://github.com/ory/kratos/issues/4024). ## Debugging Steps ### 1. Check Your Jsonnet Mapping Configuration Create a debug version of your Jsonnet mapping to see what claims are actually being received:

jsonnet local claims = std.extVar('claims'); {   identity: {     traits: {       // Minimal traits mapping       [if 'email' in claims && claims.email_verified then 'email' else null]: claims.email,     },     metadata_public: {       // Store all received claims for debugging       debug_claims: claims     }   }, }

This approach is recommended in the [troubleshooting documentation for social sign-in](https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#redirect-loops-after-registration) and will help you see exactly what data is being received from the provider. ### 2. Verify Scope Configuration Ensure you're requesting the correct scopes. For example, with Facebook, you might need:

yaml scope:   - email

As shown in the [Facebook social sign-in documentation](https://www.ory.sh/docs/kratos/social-signin/facebook#data-mapping). ### 3. Check for Provider-Specific Issues Some providers have specific requirements. For example, with GitLab, you might need to add an explicit

issuer_url

as mentioned in [this issue](https://github.com/ory/kratos/issues/3814):

yaml issuer_url: <https://gitlab.com>

### 4. Inspect Network Requests Monitor the network requests between your application, Ory, and the OIDC provider to see where the flow might be breaking down. ### 5. Check for Incomplete Previous Flows If you've had a previous incomplete OIDC flow, you might need to clear related database entries. As mentioned in [this issue](https://github.com/ory/kratos/issues/4024), sometimes deleting rows in the

hydra_oauth2_authentication_session

table can resolve issues with subsequent flows. ## Additional Considerations If you're using the Ory Network and want to include specific relationships (like group memberships) in your OIDC claims, note that this isn't automatically included. As mentioned in [this issue](https://github.com/ory/network/issues/267), you might need to implement a custom consent endpoint to include such data in your tokens. By following these debugging steps, you should be able to identify why your OIDC claims are empty and resolve the issue accordingly.

When configuring a generic OIDC provider in Ory Kratos, you need to specify several URLs in your configuration. Based on the knowledge sources, here's what you need to include: ## Required URLs for Generic OIDC Provider The main URL you need to specify is the Issuer URL, which is the OpenID Connect server URL used by the provider to issue tokens. This is the most important URL as Ory will use it to discover other endpoints through the provider's

.well-known/openid-configuration

endpoint. Here's an example configuration from the [Generic provider documentation](https://www.ory.sh/docs/kratos/social-signin/generic):

yaml selfservice:   methods:     oidc:       config:         providers:           - id: generic # this is `<provider-id>` in the Authorization callback URL             provider: generic             client_id: .... # Replace with your Client ID             client_secret: .... # Replace with your Client Secret             issuer_url: <https://accounts.google.com> # Replace with your provider's issuer URL             mapper_url: "base64://{YOUR_BASE64_ENCODED_JSONNET_HERE}"             scope:               - email             claims_source: id_token  # default value       enabled: true

## UserInfo Endpoint Configuration By default, Ory reads claims from the identity token supplied through the provider's token endpoint. However, you can configure Ory to use the UserInfo endpoint instead by setting the

claims_source

parameter to `userinfo`:

yaml claims_source: userinfo  # default is "id_token"

As mentioned in the [Generic provider documentation](https://www.ory.sh/docs/kratos/social-signin/generic#claims-source), this will make Ory call the UserInfo endpoint as discovered through the provider's

.well-known/openid-configuration

URL. ## Other Provider-Specific URLs For some providers that don't fully support auto-discovery, you might need to explicitly specify additional URLs. For example, in the [LINE provider configuration](https://www.ory.sh/docs/kratos/social-signin/line), you can see they explicitly define:

yaml auth_url: <https://access.line.me/oauth2/v2.1/authorize> token_url: <https://api.line.me/oauth2/v2.1/token>

However, for most standard OIDC providers, specifying just the

issuer_url

is sufficient as Ory will discover the other endpoints automatically. Remember to also configure your provider with the correct redirect URI, which follows this pattern:

https://$<http://PROJECT_SLUG.projects.oryapis.com/self-service/methods/oidc/callback/<provider-id|PROJECT_SLUG.projects.oryapis.com/self-service/methods/oidc/callback/<provider-id>>

If you're using PKCE, the redirect URL might be different as noted in the [PKCE documentation](https://www.ory.sh/docs/kratos/social-signin/oidc-pkce). This configuration should allow you to successfully integrate with most OIDC-compliant providers.

@chilly-king-10285 in a OIDC flow why do I get the error "Received successful OpenID Connect callback but user is not registered. Re-initializing registration flow now."

This error occurs during an OIDC flow when a user successfully authenticates with the social sign-in provider, but Ory Kratos doesn't find a matching identity in its database. This is a normal part of the flow when a new user tries to log in with a social provider for the first time. ## Why This Happens When you use social sign-in (OIDC) with Ory Kratos, the system follows these steps: 1. User is redirected to the social provider (like Google, GitHub, etc.) 2. User authenticates with that provider 3. Provider redirects back to Ory with user information 4. Ory checks if this social identity already exists in its database 5. If no matching identity exists, Ory initiates a registration flow The error message you're seeing is actually informational - it's telling you that Ory received the callback from the OIDC provider successfully, but since this user doesn't exist yet in Ory's database, it's starting a registration flow to create the account. ## Common Issues That Can Cause Problems While this message itself is normal, there are several issues that might prevent the registration from completing properly: 1. Redirect loops after registration: This can happen when the Jsonnet mapping configuration for the social provider is incorrect, causing Ory to fail to map the provider's data to your identity schema traits. As described in the [social sign-in troubleshooting documentation](https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#redirect-loops-after-registration), this can lead to a redirect loop. 2. Missing required traits: If your identity schema requires traits that aren't provided by the social provider, the user will be redirected to the registration screen to fill in the missing information. If this isn't handled properly, it can cause confusion. 3. Traits from registration payload getting lost: As noted in [this GitHub issue](https://github.com/ory/network/issues/345), there can be issues where traits provided in the registration API flow payload with OIDC get lost. 4. Flow not continuing after registration: Another issue described in [this GitHub issue](https://github.com/ory/network/issues/352) is that SPA flows might not continue with the OAuth flow after registration. ## How to Fix It 1. Debug your Jsonnet mapping: Follow the approach described in the [troubleshooting documentation](https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#debug-jsonnet-claims-mapping):

jsonnet    local claims = std.extVar('claims');    {      identity: {        traits: {          // Minimal traits mapping          [if 'email' in claims && claims.email_verified then 'email' else null]: claims.email,        },        metadata_public: {          // Store all received claims          debug_claims: claims        }      },    }

2. Check your identity schema: Make sure your identity schema doesn't require traits that the social provider doesn't supply, or handle the missing traits properly in your UI. 3. Verify return_to parameter: Make sure you're properly handling the

return_to

parameter in your flows, as there have been [issues with this parameter not working for errors](https://github.com/ory/network/issues/344). 4. Check for incomplete previous flows: As mentioned in [this GitHub issue](https://github.com/ory/kratos/issues/4024), sometimes having incomplete previous OIDC flows can cause problems with new ones. If you continue to experience issues after implementing these fixes, you might want to check the specific GitHub issues referenced above for more detailed information about your particular scenario. Remember that this error message itself is expected behavior when a new user tries to sign in with a social provider - the key is ensuring the subsequent registration flow completes successfully.

In Ory's OIDC implementation, claims are organized with standard OpenID Connect claims at the top level, while non-standard claims are grouped under

raw_claims

. This is by design to maintain compatibility with the OpenID Connect specification. ## Why Claims Are Grouped Under

raw_claims

According to the [Kratos social sign-in data mapping documentation](https://www.ory.sh/docs/kratos/social-signin/data-mapping#raw-claims-raw_claims): > All claims that are not part of the standard userinfo claims, are mapped into

raw_claims

. This means that Ory separates claims into two categories: 1. Standard OIDC Claims: Claims defined in the OpenID Connect specification (like

email

,

name

,

given_name

, etc.) are placed at the top level of the claims object. 2. Non-Standard Claims: Any provider-specific or custom claims that aren't part of the standard OIDC specification are grouped under the

raw_claims

object. ## Accessing Raw Claims in Jsonnet To access these non-standard claims in your Jsonnet mapping, you need to reference them through the

raw_claims

property. Here's an example from the [SAML data mapping documentation](https://www.ory.sh/docs/kratos/organizations#example-saml-data-mapping):

jsonnet local claims = std.extVar('claims');  {   identity: {     traits: {       email: claims.email,       [if std.objectHas(claims, "raw_claims") && std.objectHas(claims.raw_claims, "firstName") then "firstName" else null]: claims.raw_claims.firstName,       [if std.objectHas(claims, "raw_claims") && std.objectHas(claims.raw_claims, "lastName") then "lastName" else null]: claims.raw_claims.lastName,     },   }, }

## Flattening Raw Claims (Enterprise Feature) If you're using Ory Polis (Enterprise), there is an option to flatten all raw claims into the profile instead of grouping them. As mentioned in the [Polis documentation](https://www.ory.sh/docs/polis/deploy/env-variables#flatten_raw_claims): > Set this config if you want to flatten all the raw claims into the profile instead of grouping them into profile.raw, this is needed for some OIDC providers that do not support nested objects. This is controlled by the

FLATTEN_RAW_CLAIMS

environment variable, which defaults to

false

. ## Debugging Raw Claims If you're unsure what claims are available in your specific provider's response, you can use the debugging approach mentioned in the [troubleshooting documentation](https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#debug-jsonnet-claims-mapping):

jsonnet local claims = std.extVar('claims'); {   identity: {     traits: {       // Minimal traits mapping       [if 'email' in claims && claims.email_verified then 'email' else null]: claims.email,     },     metadata_public: {       // Store all received claims for debugging       debug_claims: claims     }   }, }

This will store all claims (including raw_claims) in the identity's metadata, allowing you to inspect exactly what data is being received from your provider.