To add custom values in a self-hosted Ory Kratos OIDC flow, you need to customize both your identity schema and create a Jsonnet mapper to properly map the data from your social sign-in provider to your identity schema. Here's how to do it: ## 1. Create a Custom Identity Schema First, define a custom identity schema that includes the fields you want to store:

json {   "$schema": "<http://json-schema.org/draft-07/schema#>",   "type": "object",   "properties": {     "traits": {       "type": "object",       "properties": {         "email": {           "type": "string",           "format": "email",           "title": "E-Mail",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "credentials": {               "password": {                 "identifier": true               }             },             "verification": {               "via": "email"             }           }         },         "custom_data": {           "type": "object",           "additionalProperties": true         }       },       "required": ["email"]     }   } }

This example includes a

custom_data

object where you can store arbitrary data from your OIDC provider [Link to identity schema customization](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema). ## 2. Create a Jsonnet Mapper Create a Jsonnet file to map the OIDC provider's claims to your identity schema:

jsonnet {   identity: {     traits: {       email: claims.email,       custom_data: {         // Map custom values from the OIDC provider here         first_name: claims.given_name,         last_name: claims.family_name,         // Add any other custom fields you need       },     },   }, }

## 3. Configure the OIDC Provider Update your Kratos configuration to include the OIDC provider with the mapper:

yaml selfservice:   methods:     oidc:       config:         providers:           - id: google # this is `<provider-id>` in the Authorization callback URL             provider: google             client_id: .... # Replace with your Client ID             client_secret: .... # Replace with your Client Secret             issuer_url: <https://accounts.google.com>             mapper_url: "file:///path/to/your/mapper.jsonnet" # Path to your Jsonnet mapper             # Alternatively, use base64 encoding:             # mapper_url: "base64://{YOUR_BASE64_ENCODED_JSONNET_HERE}"             scope:               - email               - profile # Include necessary scopes to get the data you need       enabled: true

Make sure to set the redirect URL in your provider's configuration to:

http(s)://<domain-of-ory-kratos>:<public-port>/self-service/methods/oidc/callback/<social-signin-provider-id>

[Link to social sign-in configuration](https://www.ory.sh/docs/self-hosted/kratos/configuration/oidc) ## 4. Don't Forget the Session Hook To prevent users from having to log in again after sign-up, add the session hook:

yaml selfservice:   flows:     registration:       after:         oidc:           hooks:             - hook: session

This configuration allows you to map custom values from your OIDC provider to your identity schema, storing them in a structured way that you can access later in your application.

I understand you want to know how to add or access the flow ID in an OIDC flow with Ory Kratos. The flow ID is a unique identifier for each authentication flow and can be useful for tracking or customizing the user experience. In Ory Kratos, you can access the flow ID in your Jsonnet mapper through the context object. Here's how you can include the flow ID in your custom data mapping:

jsonnet function(ctx) {   identity: {     traits: {       email: ctx.claims.email,       custom_data: {         // Store the flow ID from the context         flow_id: ctx.flow.id,         // Other custom fields         first_name: ctx.claims.given_name,         last_name: ctx.claims.family_name,       },     },   }, }

The flow object is available in the Jsonnet context and contains information about the current authentication flow, including its ID. This approach allows you to store the flow ID along with other custom data in your identity traits. For webhooks, you can also access the flow ID through the context object:

jsonnet function(ctx) {   // Access flow ID from the context   flow_id: ctx.flow.id,   // Other data you want to include   user_id: ctx.identity.id, }

This is particularly useful when [integrating with external systems through webhooks](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#define-http-request), as you can include the flow ID in your webhook payload. Remember that when using Jsonnet for data mapping, you can format and lint your code using the Kratos CLI:

kratos jsonnet format --write path/to/files/*.jsonnet kratos jsonnet lint path/to/files/*.jsonnet

This ensures your Jsonnet code is properly formatted and free of syntax errors before deploying it.

I understand you're asking about maintaining the

ory_kratos_continuity

cookie in a native flow with Ory Kratos. This is particularly relevant for social sign-in flows in native applications. In native flows, managing the

ory_kratos_continuity

cookie can be challenging because native apps don't handle cookies the same way browsers do. Based on the knowledge sources, there are a few key points to understand: ## The Challenge with Continuity in Native Flows The

ory_kratos_continuity

cookie is used to maintain state during multi-step authentication flows, particularly for social sign-in. In native apps, this presents a challenge because: 1. The cookie is set during the initial flow but may not be accessible when redirecting back from the identity provider 2. There's a known issue where traits submitted in the registration API flow with OIDC can get lost because the continuity container cannot be retrieved without the cookie [Link to GitHub issue](https://github.com/ory/network/issues/345) ## Implementation for Native Apps For native apps, Ory recommends using the session token exchange code approach: 1. Initialize a login or registration flow with

return_session_token_exchange_code=true

2. When submitting the form for social sign-in, you'll receive a 422 status code with a

redirect_browser_to

URL 3. Open this URL in a browser (using something like WebBrowser.openAuthSessionAsync in React Native) 4. After authentication, the browser will redirect back to your app with a code parameter 5. Exchange this code for a session token Here's the general flow as described in the [Social sign-in for native and mobile apps documentation](https://www.ory.sh/docs/kratos/social-signin/native-apps#implementation):

1. Initialize API flow with return_session_token_exchange_code=true 2. Submit form to Ory Network 3. Receive 422 with redirect_browser_to URL 4. Open browser for authentication 5. User authenticates with identity provider 6. Browser redirects back to app with code 7. Exchange code for session token 8. Store session token securely

## Current Limitations There is a known issue with the

ory_kratos_continuity

cookie in API flows, as mentioned in a GitHub issue: > "The issue is that the continuity container (which holds the traits data) cannot be retrieved from the database without the

ory_kratos_continuity

cookie, which of course doesn't make sense in an API flow." The Ory team is working on a solution that would likely involve attaching the continuity container to the state parameter for native flows. ## Domain Configuration If you're running Kratos under a subdomain, you might also want to configure the cookie domain. While you can configure the domain for

ory_kratos_session

cookies, there's currently a limitation where you cannot configure the domain for the

ory_kratos_continuity

cookie, as noted in [this GitHub issue](https://github.com/ory/kratos/issues/2713). For now, the best approach for native apps is to follow the session token exchange code flow described above, which helps bypass some of the cookie-related challenges.

Based on your error message, you're encountering a CSRF security violation in Ory Kratos. This error typically occurs when the browser doesn't have the necessary cookies to resume a session, particularly the

ory_kratos_continuity

cookie. ## Common Causes and Solutions 1. Missing CSRF Token: When making requests to Kratos, especially for flows like login or registration, you need to include the CSRF token. For browser-based applications, you need to: - Forward the cookies from the browser to Kratos - Include the X-CSRF-Token header for GET requests - Include the csrf_token in the request body for POST requests [CSRF Error during Login Flow](https://github.com/ory/kratos/discussions/4307) shows a similar issue where despite forwarding cookies, the CSRF violation still occurs. 2. Cookie Domain Issues: If you're running Kratos on a different domain or subdomain than your application, cookies might not be properly shared. As mentioned in the [Cookie-based security model documentation](https://www.ory.sh/docs/security-model): > To manage HTTP cookies, Ory APIs must be exposed on the same domain as your application. If you don't fulfill this requirement, HTTP Cookies are ignored by the browser. 3. Browser vs. Native App Confusion: Make sure you're using the correct endpoints: - Browser apps use

/self-service/{flow-type}/browser

endpoints - Native apps use

/self-service/{flow-type}/api

endpoints [Browser vs. native apps documentation](https://www.ory.sh/docs/identities/native-browser) explains this distinction. 4. Cookie Formatting: When sending multiple cookies in the header, they need to be properly formatted:

Cookie: cookie1=value1; cookie2=value2

There was an issue reported where [Ory server only splits multiple cookies if they are terminated with ";"](https://github.com/ory/network/issues/36). 5. HTTP vs. HTTPS: If you're running over HTTP without

--dev

mode, cookies with the

Secure

flag won't be sent. From the [CSRF troubleshooting documentation](https://www.ory.sh/docs/kratos/debug/csrf): > If you want Ory Kratos to work with HTTP (for example on localhost) you can add the

--dev

flag:

kratos serve --dev

. 6. Mixing localhost and 127.0.0.1: These are considered different domains for cookies. > Make sure that you use

127.0.0.1

or

localhost

consistently across your configuration! For server-side applications making requests to Kratos, ensure you're properly forwarding all cookies and including the CSRF token. If you're using the SDK, make sure to set

withCredentials: true

in your configuration. If you're still facing issues, you might want to check your browser's network tab to see which cookies are being sent with your requests and ensure the

ory_kratos_continuity

cookie is present and being properly forwarded. Let me know if you need more specific guidance based on your implementation details.

The

ory_kratos_continuity

cookie is automatically set by Ory Kratos during multi-step flows, particularly during social sign-in (OIDC) flows. You don't need to manually create or set this cookie - Kratos handles this for you. Here's how the cookie is created and where it comes from: 1. Initial Flow Request: When you start a login or registration flow that involves social sign-in, Kratos creates a continuity container to store state information. 2. Cookie Creation: Kratos sets the

ory_kratos_continuity

cookie in the browser during the initial flow request. This happens automatically when you: - Start a login flow with an OIDC provider - Start a registration flow with an OIDC provider - Initiate other multi-step flows like account recovery 3. Cookie Storage: The browser stores this cookie and sends it back to Kratos with subsequent requests. For browser-based flows, this happens automatically. When you make a request to start a flow, the response from Kratos includes a

Set-Cookie

header with the

ory_kratos_continuity

cookie. For example, when you initiate a login flow and then click on a social sign-in provider like Google, Kratos sets this cookie before redirecting you to Google. When Google redirects you back to Kratos, your browser automatically includes this cookie, allowing Kratos to resume the flow where it left off. As noted in the [GitHub issue](https://github.com/ory/network/issues/345), this becomes challenging in API/native flows because the continuity container is tied to this cookie, which doesn't work well for non-browser environments. If you're debugging and need to see this cookie: 1. Open your browser's developer tools 2. Go to the Application/Storage tab 3. Look under Cookies for your Kratos domain 4. You should see the

ory_kratos_continuity

cookie after starting a social sign-in flow Remember that this cookie is domain-specific and, as mentioned in [this GitHub issue](https://github.com/ory/kratos/issues/2713), currently doesn't support custom domain configuration like the session cookie does. For native apps, you'll need to use the session token exchange code approach as discussed previously, as direct cookie management isn't practical in that environment.