Hi All, I’m new to ORY’s Slack, so apologies if this is not the right channel for support. If there’s a more appropriate channel, kindly guide me. We are using ORY Enterprise and have encountered a challenge while integrating authentication with a Drupal CMS OAuth2 server. I’m seeking guidance or suggestions on how to handle the issue. The Scenario: 1. We’re using ORY to authenticate against Drupal’s OAuth2 server. The authentication process works as expected. 2. The challenge arises when ORY queries the /oauth2/UserInfo endpoint on the Drupal side to fetch user information and claims for the authenticated user. Below is an example of the response we receive from Drupal:

{
  "sub": "6",
  "email": "sankettejas@gmail.com",
  "email_verified": true,
  "name": "admin",
  "preferred_username": "admin",
  "zoneinfo": "Asia/Kolkata",
  "given_name": null,
  "family_name": null,
  "roles": [
    "authenticated user",
    "administrator"
  ]
}

3. In this response, the sub field contains the user ID (6 in this example), which is the unique identifier for the user in Drupal. 4. However, when we migrated users to ORY, the unique identifier we used was the username (e.g., preferred_username), not the user ID. The Problem: Since ORY uses the sub field from the response for client-side authentication, we cannot correctly map or identify the user because sub contains the Drupal user ID. What We’re Looking For: We need to know if ORY provides a way to map the sub field on ORY's side to use the preferred_username field from the Drupal response instead of the sub value. This would allow ORY to complete client-side authentication based on the unique identifier (username) that we use. Any guidance, documentation, or solutions to handle this scenario would be greatly appreciated. Thanks in advance!

Hello @bitter-terabyte-10041 Since you are an Ory customer I would recommend to open a ticket instead. You can find the ticketing system at https://console.ory.sh/support under "Dedicated Support". Please let me know if there is any issues with accessing the ticketing system. Edit: I checked and you (or someone from your team) also created a ticket. Reposting our response for others who are looking into this:

you cannot override the

sub

claim, but using the Jsonnet mapping, you can decide where the claims from the ID token end up in the identity. So for example if you put the user's email address into the traits, and the email field is marked as an identifier in your identity schema (which is default for the

email

preset), then logins from different SSO providers that use the same email address will be merged together.

So, in order to migrate, you need a common field value (ideally the email address) that is part of the identities traits. Then, this field will be used as an identifier for the identity to ensure that only one identity with that identifier exists in the system.

Hey Hi @magnificent-energy-493,