Unique identity for Entra user authenticated via Dex

[oakad]

MSDN page about Entra discourages its users from using most claims to uniquely identify users (https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference).

For preferred_username claim (forwarded by Dex) it says: "... this value can't be used to make authorization decisions."

For email claim (also forwarded by Dex) it says: "... Never use it for authorization or to save data for a user."

Yet, it so happens, that I want some piece of info that will allow me to do authorization decisions and to be able to save data for a user on the application side.

The only claim which appears to be suitable for such role seems to be the oid, or possibly, oid + tid. These are supposed to uniquely identify a user. Yet, they are not forwarded by Dex even though I explicitly request the profile scope.

Am I missing something here? Which identifier should I use to uniquely identify an user on the application side? And if it's indeed an oid, why Dex is swallowing it somewhere?

[nabokihms]

The sub claims is a uniq identifier of a user.

[oakad]

Unfortunately, it is not.

On Entra, a sub claim is an unspecified hash of app id + tenant id + user oid. It is specific to application instance.

In intranet environments (the only place where dex is of substantial use) we usually want to establish the "global" identity of the user (via the "profile" scope). The same app may end up deployed with multiple distinct app ids (based on environment or region) but each such app id instance taps into common pool of SSO authenticated users.

People commonly use "email" as identifier (as it will seldom change in those SSO orgs), but it's not quite correct.

[nabokihms]

Dex only supports a limited number of claims https://dexidp.io/docs/configuration/custom-scopes-claims-clients/
The federated claim user id may help.

[oakad]

Federated:id pseudo-claim is simply dex's sub unpacked - that is, the wrapped entra sub.

What really prevents dex from forwarding all the claims it receives from upstream (apart from those replaced by dex's own)? Alternatively, there could be a configurable list of claims to forward - it's not difficult to do and it will be useful to a lot of users (judging from other issues).

It can be even hidden behind a pseudo-claim (like "federated:original" or something).