To create an OIDC data mapper for Microsoft that stores the identity's Microsoft tenant and its own identity id in the public metadata, you can use a Jsonnet snippet. The Microsoft tenant is typically available in the claims as the tenant ID (often under the claim oid or tid, depending on your Azure AD setup), and the identity's own id is available as sub in the claims. Here is an example Jsonnet data mapper that accomplishes this:

jsonnet local claims = std.extVar('claims');  {   identity: {     traits: {       [if 'email' in claims then 'email' else null]: claims.email,     },     metadata_public: {       microsoft_tenant: claims.tid, // 'tid' is the tenant ID claim from Microsoft       microsoft_identity_id: claims.sub, // 'sub' is the unique identifier for the user     },   }, }

-

claims.tid

stores the Microsoft tenant ID. -

claims.sub

stores the unique identity ID from Microsoft. This approach is based on the documented method for mapping claims to traits and metadata in Ory Kratos, and follows the pattern for setting public metadata as shown in the [official documentation](https://www.ory.sh/docs/kratos/social-signin/data-mapping#write-a-jsonnet-data-mapper) and the [GitHub example](https://www.ory.sh/docs/kratos/social-signin/data-mapping#end-to-end-github-example). If your Azure AD setup uses a different claim for the tenant, adjust

claims.tid

accordingly (for example, use

claims.oid

if that's where your tenant is stored). Note: The knowledge sources confirm that you can set public metadata fields in the data mapper, and that claims such as

sub

and tenant information are available in the claims object provided by Microsoft OIDC responses. If you need to map a different claim, inspect the actual claims returned by your Microsoft OIDC provider and adjust the keys as needed. References: - [Write a Jsonnet data mapper](https://www.ory.sh/docs/kratos/social-signin/data-mapping#write-a-jsonnet-data-mapper) - [End-to-end GitHub example](https://www.ory.sh/docs/kratos/social-signin/data-mapping#end-to-end-github-example)

The knowledge sources do not explicitly describe a recommended way to inject client secrets into Jsonnet code or the OIDC configuration when running inside a pipeline. However, they do provide some relevant guidance: - Do not store secrets directly in Jsonnet code snippets. Jsonnet data mapping snippets are not stored encrypted in Ory Network, so secrets should not be included in them. - Client secrets are configured in the OIDC provider configuration, not in the Jsonnet data mapping. For example, in the Ory Identities or Kratos configuration YAML, you set

client_secret: ....

for each provider. This value can be templated or injected by your pipeline tool when generating the configuration file before applying it to Ory:

yaml   selfservice:     methods:       oidc:         config:           providers:             - id: microsoft               provider: microsoft               client_id: .... # Injected by your pipeline               client_secret: .... # Injected by your pipeline               # ...

- Environment variables: While not recommended for complex objects, you can set the full JSON array of providers as an environment variable if needed, as shown in the docs:

bash   export SELFSERVICE_METHODS_OIDC_CONFIG_PROVIDERS='[{"id":"google","provider":"google","mapper_url":"<file_location>","client_id":"<client_id>","client_secret":"<client_secret>","scope":["openid","email","profile"],"auth_url":"<https://accounts.google.com/o/oauth2/v2/auth>","token_url":"<https://www.googleapis.com/oauth2/v4/token>","issuer_url":"<https://accounts.google.com>"}]'

But this approach is only recommended if you are comfortable with the syntax and complexity involved. Summary: Inject the client secrets at the configuration level (YAML or environment variable) in your pipeline, not in the Jsonnet data mapping. Use your pipeline's secret management capabilities to substitute the secret values before applying the configuration to Ory Kratos or Ory Network. Do not put secrets in Jsonnet code snippets, as they are not encrypted or protected in that context. For more details, see the section on [OIDC provider configuration and environment variables](https://www.ory.sh/docs/self-hosted/kratos/configuration/oidc) in the documentation.

@chilly-king-10285 an i read in a json file which has key values where it's provider id: client secret

I'm sorry, but the knowledge sources do not contain information about reading in a JSON file with provider IDs and client secrets directly into the Ory configuration or Jsonnet data mapping. The documentation only describes setting client secrets directly in the OIDC provider configuration section of your YAML or via environment variables, and explicitly warns not to store secrets in Jsonnet data mapping snippets. There is no mention of a built-in mechanism to import secrets from an external JSON file at configuration time or within Jsonnet code itself. If you need to automate secret injection, you would need to handle reading the JSON file and injecting the secrets into your configuration using your pipeline or deployment tooling before applying the configuration to Ory. This process is not covered in the provided documentation sources.

To prevent the creation of an identity when the OIDC response does not contain a verified email (and avoid triggering manual verification), you should use a Jsonnet data mapper that only maps the email trait if the email is present and marked as verified by the OIDC provider. If the email is not verified, the trait will be missing, and Ory will reject the registration due to a missing required field in the identity schema. Here’s how you can do it: 1. Require the email trait in your identity schema and mark it as required. 2. Use a Jsonnet data mapper that only sets the email trait if the email is present and verified:

jsonnet    local claims = { email_verified: false } + std.extVar('claims');     {      identity: {        traits: {          [if 'email' in claims && claims.email_verified then 'email' else null]: claims.email,        },      },    }

If the OIDC provider does not return a verified email, the

traits.email

field will be missing. Since your identity schema requires this field, Ory will return a validation error and will not create the identity or trigger manual verification. This approach is explicitly recommended in the documentation to prevent account enumeration and other attack vectors related to unverified emails from social sign-in providers [Write a Jsonnet data mapper](https://www.ory.sh/docs/kratos/social-signin/data-mapping#emails-and-phone-numbers). Summary: - Require

traits.email

in your identity schema. - Use a Jsonnet data mapper that only sets

traits.email

if the email is present and verified. - If the email is not verified, registration fails and no identity is created. This ensures that only users with a verified email from the OIDC provider can register, and no manual verification is triggered.