tid + oid a mistake?

[s-andringa]

In #33 was concluded that Microsoft advises to use tid+oid as the uid, and now, starting from version 3 this gem uses that to identify users. From what I can tell, this decision was based on a particular section from this document, stating:

Multi-tenant applications should index on a mapping of two uniquely identifying claims, tid + oid. This will segment tenants by the tid, and segment users by their oid.

However, to me that does not unequivocally imply that oid alone may not be unique across tenants and that the two claims should be concatenated for reliable identification. Many other sources from Microsoft contradict this.

For instance, in the same document is stated that identification should be performed based on a globally unique identifier (GUID), while this page tells us that oid alone is a GUID:

This ID uniquely identifies the user across applications [...]. The oid claim is a GUID and can't be reused.

Here someone from Microsoft confirms that oid is unique:

I assume you are referring to the object ID/oid attribute. If this is the case, the oid claim or ObjectId property is immutable and unique, so it will uniquely identify the relevant directory object. When a single user resides in multiple Entra ID tenants, the user will contain a different object ID/oid in each tenant.

And, finally the most unmistakable statement from this page:

Use claims to reliably identify a user

When identifying a user, it's critical to use information that remains constant and unique across time. [...] Instead, use the claims provided by the OIDC standard, or the extension claims provided by Microsoft - the sub and oid claims.

To correctly store information per-user, use sub or oid alone (which as GUIDs are unique), with tid used for routing or sharding if needed. [...]

At this point, I am not fully convinced that this change and the migration that it necessitates are actually necessary. I’d genuinely appreciate it if you could share any additional sources or reasoning to support this decision.

For now, we are opting out of tid+oid. For anyone who wishes to do the same: it can be done by subclassing the entra_id strategy and defining your own uid builder using the uid macro:

module OmniAuth
  module Strategies
    class EntraIdWithOid < OmniAuth::Strategies::EntraId
      uid { raw_info["oid"] }
    end
  end
end 

[pond]

Sorry for delay. RIPA couldn't survive the dire economic conditions caused by our current administration's ill-advised austerity-based approach to financial "management" and closed down a few weeks ago. I don't know if I'll be able to keep maintaining this software in my free time; I'd certainly have to fork it to my own repo and publish from there.

Anyway, I wasn't an expert on the TID + OID stuff and relied upon the submitter of the prior PR for this. It was painful, too, given the need to create a new major version and migrate our own code base. Microsoft's documentation on anything to do with Entra or AAD - and some of it is still called Active Directory, sigh - can be, if I'm being both very charitable and polite, described as a total clusterfuck. If I were being uncharitable and impolite, I'd use stronger language 😂

If it is indeed possible to not have the TID+OID for people confident in that... Well, I'm open to suggestions on how to sort that out in the gem. We don't want yet another new major version / backwards compatibility breakage. Perhaps it's just a question of updating the documentation?

[pond]

@s-andringa Any further thoughts re. the above comment? I could as an alternative have a configuration-based way to make that behaviour optional (if it does not already have such a thing - it's March and I had shoulder surgery mid-Feb on top of anything else, plus still hunting for a job, so I've forgotten a lot of details about the gem).

[pond]

@s-andringa An official way to do this is now available in v3.1.0; set the "ignore_tid" option. Thanks for spending so much time documenting the information - it will be helpful for others trying to decide the best course of action (which, perhaps most of the time, will turn out to be ignoring TID!)