Sign-in methods

Your users may sign in through any of the methods the operator has enabled. From your application's point of view this is transparent: you always run the same OAuth code + PKCE flow, and the resulting token tells you which method was used via the properties.source claim.

What you receive

Every successful sign-in yields an access token whose properties object contains a stable userID, the user's email and name (when available), the source (the method used), and the roles / permissions granted to the user for your application. Identify a returning user by userID (stable across sessions and methods), not by email.

source values

Notes for integrators

• Email is not guaranteed. Some methods do not return an email address —

notably X, which exposes only an account id and name. Do not assume email is always present; key your records on userID.

• The available methods are runtime-configured. Which methods appear on the

sign-in screen, and in what order, is decided by the operator and can change without any change on your side — your integration does not need to know the list in advance.

• Roles & permissions are app-scoped. The roles and permissions in the

token reflect what the user is granted for your application (aud). Enforce authorization from these claims server-side.