IDENTITY ACCESS
Console

How sign-in works

What happens between the button press and the user appearing on your site.

We use the Authorization Code Flow with mandatory PKCE — what is today considered correct for every kind of application.

Step by step

  1. The user presses "Sign in". Your site sends them to /auth with its client_id, redirect URI and a code_challenge.
  2. auth.my shows the sign-in screen. The user picks the method: emailed code, passkey, Google, Entra, backup code.
  3. If your site is asking for data for the first time, a consent screen lists what it will receive.
  4. The user returns to your redirect URI with a one-time authorization code.
  5. Your site exchanges it for tokens at /token, presenting the code_verifier.

The code lives 10 minutes and is exchanged once. A second exchange always signals tampering and is rejected.

Why PKCE

The authorization code travels through the browser — that is, through other people's hands: extensions, proxy logs, history. Whoever intercepts the code could otherwise exchange it for tokens.

PKCE closes that. Your site invents a secret (code_verifier) in advance, sends only its hash to the authorization request, and presents the original at exchange time. An intercepted code without the verifier is worthless.

PKCE is required for everyone here, including server-side clients that hold a secret. Recent libraries enable it on their own.

Shown once per set of scopes. Ask for a new scope and consent is requested again.

The screen shows your site's name and logo. Until the client's domain is verified, a warning states that these are unverified; verification is a TXT record in DNS, done on the client's page in the console.

Signing in again

If the user still has a session with auth.my and consent is in place, they see nothing the second time: the browser visits /auth and comes back with a fresh code by itself. This is why "sign in again" after tokens expire is usually invisible.

What can go wrong

The user blocked your site. Their console has a block button under Connected sites. After that sign-in stops working and tokens stop refreshing.

The application is employees-only. If the client is restricted to an organization, an outsider is either refused or, when the organization accepts external members, taken through a joining screen.

Error details are in Errors.

Did this page help?