id  |   String   |   The unique identifier for the object. For example, 12345678-9abc-def0-1234-56789abcde. The value of the id property is often but not exclusively in the form of a GUID; treat it as an *opaque identifier* and do not rely on it being a GUID. Key. Not nullable. Read-only.

How would you treat this string in your database? Say you needed to save this value in your database. varchar(50)?

it just means you can't guess the thing being identified solely based on the identifier value

Some better context of where that string you included came from might be helpful (I'm guessing it's this: https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0 ?). They're basically saying that that field is used as a unique identifier, and it should be not-easily-guessable. However this is a reference to your own storage, right? So the decision on what constitutes that unique identifier is up to you. They're describing the purpose; it's up to you what the implementation is. If yer on SQL Server, and you want to use a GUID, then use type (from memory)

UniqueIdentifier

. If yer using something else, then use a char file wide enough to store the GUID. If yer using yer own scheme to come up with a unique identifier (DO NOT DO THIS), then make it as wide as that scheme dictates.

thats exactly the source Adam. and yes I'm on SQL server. Imma go with UniqueIdentifier. In our local system I already have mechanisms in place to prevent duplicate users(emails) so when I search for a users id in AD by email and I get 1 result I'm saving that sucker, if I get more than 1 I need to start another process which results in eliminating duplicates from AD.