Based on the available knowledge sources, the Jsonnet mapping used in the session-to-JWT feature (i.e., customizing JWT claims via a Jsonnet template in the tokenizer configuration) has access to the Ory Session object, which includes the full identity object. This identity object contains the metadata_admin field, as shown in the session structure documentation and the JWT claims mapping documentation. In your Jsonnet template, you can access session.identity.metadata_admin and include its values in the JWT claims as needed. For example:

jsonnet local claims = std.extVar('claims'); local session = std.extVar('session');  {   claims: {     admin_metadata: session.identity.metadata_admin,     // ... other claims   } }

This approach allows you to expose metadata_admin in the JWT if required. However, be aware that metadata_admin is intended for admin/internal use and may contain sensitive information, so exposing it in JWTs (which may be accessible to clients) should be done with caution. The documentation does not mention any restrictions on accessing metadata_admin in the session-to-JWT Jsonnet mapping, and the session object structure confirms its presence as a field you can reference in your template [Convert Ory Sessions to JSON Web Tokens](https://www.ory.sh/docs/identities/session-to-jwt-cors#json-web-token-templates) [Session-management Overview](https://www.ory.sh/docs/kratos/session-management/overview). If you need to set or update metadata_admin, that must be done via admin APIs or during identity mapping (e.g., during social sign-in), not in the JWT mapping itself [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata). Summary: Yes, you can use metadata_admin in the Jsonnet mapping for the session-to-JWT feature by referencing it from session.identity.metadata_admin in your claims template.

Yes, you can include your metadata_admin property (e.g., azure_adb2c_user_id) as a custom claim (such as oid) in the JWT when using the session-to-JWT feature. The Jsonnet template used for customizing JWT claims has access to the full session object, including session.identity.metadata_admin. You can map this property to any claim in the JWT as shown below:

jsonnet local claims = std.extVar('claims'); local session = std.extVar('session');  {   claims: {     oid: session.identity.metadata_admin.azure_adb2c_user_id,     // ... other claims   } }

This will set the oid claim in the JWT to the value of azure_adb2c_user_id from metadata_admin, provided that this property exists on the identity. Please note that metadata_admin is intended for admin/internal use, so ensure you are not exposing sensitive information unintentionally [Convert Ory Sessions to JSON Web Tokens](https://www.ory.sh/docs/identities/session-to-jwt-cors#json-web-token-templates) [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata).

I'm sorry you're encountering this error. Based on the knowledge sources, your approach to referencing metadata_admin in the Jsonnet mapping for session-to-JWT is correct in principle, as the session object should include identity and its metadata fields [Convert Ory Sessions to JSON Web Tokens](https://www.ory.sh/docs/identities/session-to-jwt-cors#json-web-token-templates). However, the error message:

"reason": "Unable to execute tokenizer JsonNet.", "message": "The request was malformed or contained invalid parameters"

suggests that there may be an issue with the Jsonnet code or with the data available in the session object at runtime. Troubleshooting steps: 1. Check for Null or Missing Fields: If

azure_adb2c_user_id

does not exist on

metadata_admin

for a given identity, referencing it directly will cause a Jsonnet error. To avoid this, use a conditional or default value:

jsonnet    local claims = std.extVar('claims');    local session = std.extVar('session');     {      claims: {        oid: if 'azure_adb2c_user_id' in session.identity.metadata_admin             then session.identity.metadata_admin.azure_adb2c_user_id             else null,      }    }

2. Debug the Session Object: To see what data is actually available, you can temporarily include the full metadata_admin in your JWT claims for debugging:

jsonnet    local claims = std.extVar('claims');    local session = std.extVar('session');     {      claims: {        debug_metadata_admin: session.identity.metadata_admin,      }    }

Then inspect the resulting JWT to verify the structure. 3. Jsonnet Syntax: Ensure your Jsonnet syntax is valid. The knowledge sources recommend using the Ory CLI to lint and format your Jsonnet code:

kratos jsonnet lint path/to/your.jsonnet    kratos jsonnet format --write path/to/your.jsonnet

[Data mapping with Jsonnet](https://www.ory.sh/docs/kratos/reference/jsonnet) 4. Field Existence: The documentation notes that metadata fields are not validated by the identity schema, so if the field is missing or misspelled, it will not be present in the session object [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata). Summary: The most likely cause is that the field does not exist for the identity, or the Jsonnet code does not handle missing fields gracefully. Use conditional checks as shown above to avoid errors when the field is missing. If you continue to have issues, you may want to debug by outputting the full metadata_admin object as described, and ensure your Jsonnet is valid and matches the actual data structure. If the problem persists even after these checks, the knowledge sources do not provide further troubleshooting steps specific to this error.

Based on the knowledge sources, the session-to-JWT feature in Ory Network allows you to use a Jsonnet template to customize JWT claims, and the session object provided to the template includes the full identity object, which contains metadata_admin [Convert Ory Sessions to JSON Web Tokens](https://www.ory.sh/docs/identities/session-to-jwt-cors#json-web-token-templates). The documentation shows examples of referencing fields from session.identity in the claims. However, the knowledge sources do not explicitly state whether you can include the entire metadata_admin object as a claim in the JWT, nor do they mention any restrictions or limitations on the size or structure of claims in the JWT produced by the tokenizer. There is also no mention of a "response blocked" error or similar behavior when attempting to include large or complex objects. Given this, it is possible that Ory Network enforces internal restrictions on what can be included in JWT claims (for example, to prevent very large tokens or to avoid exposing sensitive data), but the knowledge sources do not provide details on this. If you are receiving a "response blocked" or similar error when trying to include the whole metadata_admin object, this behavior is not documented in the provided sources. Summary: The knowledge sources do not contain enough information to explain why including the entire metadata_admin object in a JWT claim would result in a blocked response in Ory Network. If you need further clarification, you may need to contact Ory support or consult additional documentation not included in the provided sources.

No, you do not need to define your custom

metadata_admin

property in your identity schema. According to the documentation, metadata fields (

metadata_admin

and

metadata_public

) are not validated using the identity's JSON schema. You are responsible for ensuring that the metadata you store is valid according to your needs, but the schema itself does not enforce or require the existence of specific metadata fields [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata). So, you can add custom properties to

metadata_admin

without updating your identity schema.

Yes, what you are seeing in the Ory Console under the "Admin metadata" section is the content of the

metadata_admin

field for that identity. This field is designed to store admin-only metadata, such as your custom property

azure_ad_b2c_user_id

. These properties are not defined or validated by the identity schema and can be set or updated via the admin APIs or through data mapping during identity creation or social sign-in flows [Identity metadata & traits](https://www.ory.sh/docs/kratos/manage-identities/managing-users-identities-metadata). So, your example:

json {   "azure_ad_b2c_user_id": "9bf5c2dd-209c-45ea-8fd9-a6fab5XXXX" }

is a valid and expected use of the

metadata_admin

field in Ory.

Yes, you can use the Ory CLI to lint Jsonnet files. The command is:

ory lint lint path/to/files/*.jsonnet [more/files.jsonnet] [supports/**/{foo,bar}.jsonnet] [flags]

This command uses the official Jsonnet linter and will exit with a status code of 1 if issues are detected. You can find more details in the documentation for [ory lint lint](https://www.ory.sh/docs/cli/ory-lint-lint#ory-lint-lint).

When you run the Ory CLI lint command and see the message:

Linter found issues.%

it means that the Jsonnet linter has detected problems in your Jsonnet files. The linter will exit with a status code of 1 and print all found lint errors to stderr. You should review the output for specific error messages that indicate what needs to be fixed in your Jsonnet code. The knowledge sources confirm this behavior for both the Ory CLI and Kratos CLI lint commands [ory lint lint](https://www.ory.sh/docs/cli/ory-lint-lint#ory-lint-lint) [kratos lint lint](https://www.ory.sh/docs/kratos/cli/kratos-lint-lint#kratos-lint-lint). If you do not see detailed error messages, make sure you are checking the full output (including stderr) from the command.