Claims you can trust

Your app reads a token and personalizes the screen: the plan, the region, a verified phone. Your goal: tell which facts a user can change and which are locked.

Use only signed claims

A claim is one fact inside a signed token, such as your name, plan or region. The IdP signs the token. So your app can trust the claim without asking a database. Personalize only from signed claims. Never use a query parameter, a header or localStorage. Anything the browser can set, an attacker can set too. For the parts of a token, see the tokens lesson.

Two kinds of profile data

User-writable metadata holds cosmetic things such as theme and language. The user sets them through a self-service API. Platform-controlled metadata holds entitlements such as plan, region and roles. Only a login hook or an admin can write them. Put anything an attacker would like to change on the platform side.

From "typed" to "proven"

A self-asserted attribute is a fact you simply typed, such as a phone number. Nobody has proven it, so it is not trusted. A verified attribute is one you proved you control. For a phone, you enter a one-time code (OTP) sent to that handset. Then the number moves to platform-controlled data. It appears in the token as the standard claim phone_number_verified. Send 2FA codes, recovery links and payment alerts only to a verified number.