This behavior is expected and is related to how Ory handles subject identifiers in OAuth2 and OpenID Connect. The subject identifier (

sub

) in your access token might be different from the actual identity ID due to subject anonymization, which is a security feature. Ory offers two subject identifier algorithms: 1. Public algorithm (default): Provides the same subject value to all clients 2. Pairwise algorithm: Provides a different subject value to each client, preventing correlation of user activity across different clients The subject value you're seeing in the decoded token is likely an obfuscated version of the actual identity ID. This is intentional to protect user privacy and prevent tracking across different applications. As mentioned in the Ory documentation: > While Ory handles

sub

obfuscation out of the box, you can also override this value with your own obfuscated

sub

value by setting

force_subject_identifier

when accepting the login request in your custom OAuth2 login app. [Ory Hydra Guides: Subject Anonymization](https://www.ory.sh/docs/hydra/guides/openid) If you need to match the subject to your identity system, you have a few options: 1. Configure your OAuth2 setup to use the public algorithm if you want consistent subject IDs 2. Use the

force_subject_identifier

option in your login provider to set a specific subject value 3. Implement a mapping in your application between the obfuscated subject IDs and your actual identity IDs If you're using a custom login provider with Ory Hydra, you can control this behavior when accepting the login request.

I understand you're using the public algorithm but still can't match the subject ID in the JWT to any identity ID in your system. Let me suggest a few other possibilities based on the knowledge sources. ### Possible Explanations 1. Subject Source Configuration: If you're using a social sign-in provider like Microsoft, the subject identifier might be coming from a different source than expected. For example, Microsoft can use different fields as the subject identifier: > By default, Microsoft uses the identifier taken from the

sub

field of OIDC

id_token

... However, some systems use the

id

field returned by the

<https://graph.microsoft.com/v1.0/me>

endpoint as a subject identifier. Others use the

oid

(Object ID) to identify users across different services. [Microsoft Social Sign-in Documentation](https://www.ory.sh/docs/kratos/social-signin/microsoft#subject-identifier-source) 2. JWT Bearer Grant Type: If you're using JWT as an authorization grant, the subject in the resulting token might be influenced by the trust relationship configuration: > The JWT must contain a

sub

(subject) claim that identifies the principal as the subject of the JWT (e.g., the user ID). This value should match the

subject

value of the trust relationship unless

allow_any_subject

is

true

. [JWT Assertion Validation Requirements](https://www.ory.sh/docs/hydra/guides/jwt#jwt-assertion-validation-requirements) 3. Subject Overriding: The subject might have been overridden during the login process: > You can also override this value with your own obfuscated

sub

value by setting

force_subject_identifier

when accepting the login request in your custom OAuth2 login app. [Subject Anonymization](https://www.ory.sh/docs/hydra/guides/openid) ### Troubleshooting Steps 1. Check for Subject Mapping: In Ory Keto, subjects can be mapped to different identifiers: > A subject ID can be any string. The application must map its resources to a constant, unique identifiers. [Keto Subjects Documentation](https://www.ory.sh/docs/keto/concepts/subjects) 2. Verify Login Flow: If a user is trying to log in with a different subject than previously used, this could cause issues: > If a user has already logged in with a subject (for example, "user-A"), and she wants to log in as another user using

login_hint

(for example,

login_hint=user-B

), directly accepting the latter login request in your login provider will cause an error. [Using Login Hint with Different Subject](https://www.ory.sh/docs/hydra/guides/openid) 3. Check for Whitespace Issues: There have been issues with whitespace-padded subject IDs in Ory: > Display of whitespace-padded subject IDs is broken in the Console. When deleting such a relationship, the subject ID is ignored, treating that field as a wildcard during deletion. This was reported in a GitHub issue for Ory Network. If none of these suggestions help, you might need to examine your specific implementation more closely, particularly how your application is handling the subject identifiers and how your login provider is configured. Would you like me to elaborate on any of these potential causes or suggest more specific troubleshooting steps?

Yes, it's possible that the subject ID in your JWT could be from a deleted identity. When an identity is deleted in Ory Kratos, the OAuth2 tokens and sessions might not be automatically invalidated. According to the Ory Kratos API documentation, when you delete an identity using the

deleteIdentity

endpoint: > Calling this endpoint irrecoverably and permanently deletes the identity given its ID. This action can not be undone. [Kratos API Reference](https://www.ory.sh/docs/kratos/reference/api) However, there's no explicit mention that this automatically invalidates all related OAuth2 tokens. While Ory provides a method to delete an identity's sessions using the

deleteIdentitySessions

endpoint: > Calling this endpoint irrecoverably and permanently deletes and invalidates all sessions that belong to the given Identity. [Kratos API Reference](https://www.ory.sh/docs/kratos/reference/api) This suggests that session invalidation is a separate operation from identity deletion. If you've deleted an identity but didn't explicitly invalidate its sessions or OAuth2 tokens, it's possible that existing tokens remain valid until they expire naturally, and they would still contain the subject ID of the now-deleted identity. To verify this hypothesis, you could: 1. Check if the subject ID in your JWT matches any previously deleted identity IDs 2. Ensure that when deleting identities, you also call the endpoint to delete all associated sessions 3. Consider implementing a token validation step in your application that checks if the identity still exists This would explain why you're seeing a subject ID that doesn't match any existing identity in your system while using the public algorithm.