Scopes and claims
What you can ask for and what comes back.
Scopes
| Scope | What it gives |
|---|---|
openid | required; without it this is OAuth, not sign-in |
profile | name and last profile update time |
email | email address and whether it is verified |
phone | phone number and whether it is verified |
offline_access | a refresh token that outlives the user's session |
Ask only for what you need. Every extra scope is another line on the consent screen and another reason to decline.
A refresh token is issued without offline_access too — it simply lives as
long as the user's auth.my session. Ask for offline_access only if you
need access while they are away.
offline_access needs the user's consent once: the first request that asks
for it leads to the consent screen with its own line — you don't need
prompt=consent for that. Once the person has agreed, later sign-ins by the
same person into the same app get offline_access silently, with no screen
and no prompt=consent, as long as the requested scopes stay the same.
prompt=consent still works as before and forces the screen every time,
even when consent was already given.
Claims
They arrive in the id_token and in the /me response.
| Claim | From scope | What it is |
|---|---|---|
sub | openid | permanent identifier — store this one |
name | profile | display name |
updated_at | profile | when the profile last changed |
email | email | email address |
email_verified | email | always true: unverified addresses do not exist here |
phone_number | phone | phone number |
phone_number_verified | phone | whether it is verified |
Plus fields that do not depend on scope:
| Claim | What it is |
|---|---|
iss | issuer, exactly https://auth.my |
aud | your client_id |
exp, iat | expiry and issue time |
amr | how they signed in |
auth_time | when the person last actually authenticated |
sid | session identifier |
About email_verified
The value is always true, and that is not a placeholder: an address only
enters an account after verification — either by emailed code, or from
a social provider that stated the address is verified.
Microsoft never sends that statement, so on a first Entra sign-in we additionally ask for an emailed code.
What is missing
There are no groups, roles or custom user attributes in the token. Roles
inside your application are your data model: tie them to sub and manage
them on your side.