Ory Kratos does not support assigning different identity schemas to different login methods within the same project or identity. Instead, each identity is associated with a single identity schema, which defines the available traits and how those traits are used across all enabled login methods (e.g., password, passkey, code, WebAuthn, TOTP). However, you can define multiple identity schemas for different types of users (e.g., customers, employees, service accounts), and assign the appropriate schema to each identity when it is created. Each schema can specify which fields are used for which login methods by using the

<http://ory.sh/kratos|ory.sh/kratos>

extensions within the schema. For example, you can specify that the

email

trait is used for password login, while the

username

trait is used for another method, or allow both as identifiers for the same method. But you cannot configure Kratos to use one schema for password login and a different schema for passkey login for the same identity. Key points: - Each identity has one schema, but you can have multiple schemas in your project for different user types. - The schema itself defines which traits are used for which login methods by marking them with the appropriate extensions (e.g.,

password.identifier

,

webauthn.identifier

,

passkey.display_name

, etc.). - You cannot assign different schemas based on the login method being used; the schema is tied to the identity, not the method. Example: A schema that allows both email and username for password login, and email for passkey and code login:

json {   "$schema": "<http://json-schema.org/draft-07/schema#>",   "type": "object",   "properties": {     "traits": {       "type": "object",       "properties": {         "email": {           "type": "string",           "format": "email",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "credentials": {               "password": { "identifier": true },               "passkey": { "display_name": true },               "code": { "identifier": true, "via": "email" }             }           }         },         "username": {           "type": "string",           "<http://ory.sh/kratos|ory.sh/kratos>": {             "credentials": {               "password": { "identifier": true }             }           }         }       }     }   } }

This schema allows both email and username for password login, but only email for passkey and code login. You can create other schemas for other user types, but not per login method for the same identity. For more details, see the documentation on [customizing identity schemas](https://www.ory.sh/docs/kratos/manage-identities/customize-identity-schema#multiple-identifiers) and [managing multiple schemas](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata#traits).

To identify user types and tell Ory Kratos which identity schema to use, you assign a specific

schema_id

when creating each identity. The

schema_id

determines which schema (and thus which traits and validation rules) will be used for that identity. This is typically done based on your application's logic for distinguishing user types (e.g., customer, employee, service account). How to do it: 1. Define multiple schemas in your Kratos configuration, each with a unique

id

and URL. For example, you might have a

customer

schema and an

employee

schema. 2. When creating an identity, specify the appropriate

schema_id

in the API request payload. This tells Kratos which schema to use for that identity. Example configuration:

yaml identity:   default_schema_id: person   schemas:     - id: customer       url: <http://foo.bar.com/customer.schema.json>     - id: person       url: <http://foo.bar.com/person.schema.json>

Example API request to create an identity with a specific schema:

json POST /admin/identities {   "schema_id": "customer",   "traits": {     "email": "<mailto:user@example.com|user@example.com>"   } }

In your application logic, you determine the user type (e.g., by registration flow, admin selection, or other criteria) and set the

schema_id

accordingly when calling the Kratos Admin API. Summary: - You identify user types in your application logic. - You assign the correct

schema_id

when creating the identity. - Kratos uses the specified schema for that identity. For more details, see the documentation on [identity traits and schemas](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata#traits) and [defining identity schemas](https://www.ory.sh/docs/migrate-to-ory#define-identity-schema).

New message text here

A message from kapa.ai

You can specify which identity schema to use during user registration flows in Ory Kratos by passing the

identity_schema

query parameter when initiating the registration flow. This is supported for both browser and native registration flows. For example: - Browser registration flow:

GET /self-service/registration/browser?identity_schema=<your-schema-id>

- Native registration flow:

GET /self-service/registration/api?identity_schema=<your-schema-id>

The

identity_schema

parameter allows you to select which schema will be used for the registration flow and, consequently, for the identity that is created upon successful registration. This is documented in the API references for both browser and native registration flows, where

identity_schema

is listed as an optional query parameter to specify the schema to use for the registration flow^{[API Reference - Browser Registration Flow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json)}^{[API Reference - Native Registration Flow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json)}. If you do not provide this parameter, Kratos will use the default schema configured for your project. In summary: To use a specific schema during user registration, pass the

identity_schema

query parameter with the desired schema ID when starting the registration flow.

To specify which identity schema to use during user registration flows in Ory Kratos, you can pass the schema ID using the

identity_schema

query parameter when initiating the registration flow. This is supported for both browser and native registration flows. How to pass the schema ID: - Browser registration flow:

GET /self-service/registration/browser?identity_schema=<your-schema-id>

- Native (API) registration flow:

GET /self-service/registration/api?identity_schema=<your-schema-id>

This parameter instructs Kratos to use the specified schema for the registration flow, and the identity created upon successful registration will be associated with that schema. This is documented in the API references for both browser and native registration flows: > |identity_schema|query parameter|string|False|An optional identity schema to use for the registration flow.|{'type': 'string'}| [Kratos API Reference – createBrowserRegistrationFlow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json) [Kratos API Reference – createNativeRegistrationFlow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json) Summary: To use a specific schema during user registration, include the

identity_schema

query parameter with your desired schema ID when starting the registration flow. The rest of the registration process remains unchanged, and the created identity will use the specified schema. If you need to distinguish user types, your application logic should determine which schema ID to use and pass it accordingly when initiating the registration flow.

Thank you for your clarification. Based on the provided knowledge sources, the ability to pass the

identity_schema

query parameter during registration flows is documented in the API references. However, the documentation does not explicitly state whether this feature is available in the open source Ory Kratos or is limited to Ory Network (the managed cloud offering). The API references mention the

identity_schema

parameter for both browser and native registration flows, but they also note that some parameters (such as

organization

) are only effective in Ory Network. There is no explicit statement in the knowledge sources confirming that

identity_schema

is supported in the open source Kratos image. Therefore, I cannot confidently confirm that this feature is available in open source Kratos based on the provided documentation. In summary: The knowledge sources do not contain enough information to confirm that passing the

identity_schema

parameter during registration flows is supported in the open source Kratos image. If you require this functionality, please consult the official Ory Kratos repository or community for the most up-to-date and definitive answer regarding open source support for this feature. If you need to assign different schemas in open source Kratos, the documented approach is to set the

schema_id

when creating identities via the Admin API, not during self-service registration flows [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata#traits).

To migrate a user's identity schema after they have signed in with an OIDC provider in Ory Kratos, you need to update the user's

schema_id

and ensure their traits match the new schema. This process is typically done using the Admin API. Steps to migrate an identity to a new schema: 1. List all identities and find the one you want to update.

bash    ory list identities --format json-pretty

2. Note the identity's ID that you want to update. 3. Update the identity's schema and traits using the

patchIdentity

API. You must: - Change the

schema_id

to the new schema. - Add, remove, or update traits as required by the new schema. Example using `curl`:

bash    curl --location --request PATCH "https://$<http://ORY_SLUG.projects.oryapis.com/admin/identities/$IDENTITY_ID|ORY_SLUG.projects.oryapis.com/admin/identities/$IDENTITY_ID>" \    --header "Authorization: Bearer $ORY_API_KEY" \    --header "Content-Type: application/json" \    --data-raw '[      {        "op": "replace",        "path": "/schema_id",        "value": "{new-schema-id}"      },      {        "op": "remove",        "path": "/traits/old_trait"      },      {        "op": "add",        "path": "/traits/new_trait",        "value": "new_value"      }    ]'

Adjust the operations to match the changes required by your new schema. 4. Ensure the identity's traits are valid according to the new schema, or the update will fail. This process can be repeated for each user who needs to be migrated to a new schema after signing in with an OIDC provider. If you have many users, you can automate this process in bulk. For more details and examples, see the official documentation on [updating identities to use a new schema](https://www.ory.sh/docs/identities/model/manage-identity-schema#update-identities-to-use-a-new-schema)<source>https://www.ory.sh/docs/identities/model/manage-identity-schema#update-identities-to-use-a-new-schema&lt;/source>.

Based on the provided knowledge sources, it is not explicitly documented that you can patch (change) an identity's schema during the OIDC callback in the self-service registration or login flow. However, the knowledge sources do describe that you can modify identity data—including traits and metadata—during registration and settings flows using webhooks, if you configure the webhook to parse the response and return a modified identity object. This allows you to update traits and metadata, but there is no mention that the

schema_id

can be changed in this way during the OIDC callback or registration flow. The webhook documentation specifically discusses traits and metadata, not the schema itself [Webhook response handling](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#modify-identities). For changing the

schema_id

, the recommended and documented approach is to use the Admin API (

patchIdentity

or

updateIdentity

) after the identity has been created [Update identities to use a new schema](https://www.ory.sh/docs/identities/model/manage-identity-schema#update-identities-to-use-a-new-schema). Summary: The knowledge sources do not provide evidence that patching an identity's schema during the OIDC callback is supported. Schema changes are documented only via the Admin API after identity creation. If you need to change the schema during or after OIDC sign-in, you should do so using the Admin API after the flow is complete.