Identity provider sign-in

providers lists every sign-in provider in the order of their buttons (the Ankra platform's Auth0 as ankra, google, microsoft, …): the portal shows one "Continue with display_name" button per entry, with its icon mark, and above it one "Continue with …" button per entry of that provider's connections (Google, Microsoft, GitHub brokered by an Auth0 provider). Each button starts /v1/auth/oidc/login?provider=<name>. The first provider is the primary one: the top-level display_name, icon, silent_sign_in and connections describe it (for portals released before there could be several; its icon is left out when it is the Ankra mark those portals do not know), and a start without provider= goes there. Which providers exist is deployment configuration (ANKRA_CLOUD_OIDC_*), not a per-account setting.

The one callback every provider returns to. Verifies state against the ankracloud_oidc cookie, whose signed challenge alone says which provider the sign-in started at (a provider parameter naming another one is a state_mismatch), redeems code there (client secret and PKCE verifier), verifies the ID token (issuer, audience, nonce, expiry, RS256 or ES256 against the provider's keys; a Microsoft token's issuer is the one of the tenant its tid names, and the person is identified by tid and oid) and requires a verified email (Microsoft's only with the optional claim xms_edov true). Then it resolves the identity: a linked subject, a user with the same email whose own address is verified too (linked; a user whose address was never verified, such as a password sign-up, is not linked and the browser lands on /login?error=account_exists, as does any user when the provider does not vouch for the address), a pending invitation (accepted; refused with email_unverified when the provider does not vouch for the address) or a new account (whose email stays unverified when the provider does not vouch for it), sets the session cookies exactly like POST /v1/auth/login plus the ankracloud_sign_in_provider cookie sign-out reads, and answers 302 to return_to. Every failure answers 302 to /login?error=email_unverified|email_missing|state_mismatch|provider_error|provider_unavailable|account_exists&provider=<name> (email_unverified adds connection= when the sign-in named one); a silent attempt that found no provider session answers 302 to /login?silent=failed. Rate limited per client address (10 a minute).

The callback of a provider listed in ANKRA_CLOUD_OIDC_PROVIDERS (/v1/auth/oidc/callback/ankra, /v1/auth/oidc/callback/microsoft); the provider of the single-provider variables keeps /v1/auth/oidc/callback. It behaves exactly like that route, and a path naming another provider than the signed challenge is a state_mismatch. Rate limited per client address (10 a minute).

Answers 302 to the provider's authorization endpoint (authorization code flow with state, nonce and a PKCE S256 challenge, scope openid profile email) and sets the short-lived ankracloud_oidc cookie (HttpOnly, Secure, SameSite=Lax, 10 minutes, signed) that the callback verifies. The callback goes to <portal origin>/v1/auth/oidc/callback (or /v1/auth/oidc/callback/<provider> for a provider listed in ANKRA_CLOUD_OIDC_PROVIDERS) for the configured portal origin the browser is on; the signed cookie remembers which provider the sign-in started at. Rate limited per client address (20 a minute). Not a browser-XHR endpoint: navigate to it.

Like /v1/auth/oidc/login with the provider's sign-up screen (screen_hint=signup; a direct provider such as Google has no separate sign-up screen and gets neither screen_hint nor connection). A new identity gets an account with itself as owner; a known one is simply signed in. coupon rides in the signed challenge cookie and is redeemed for the account the sign-up creates; the landing page then carries coupon_status=applied or the reason it was not applied (unknown, inactive, not_yet_valid, expired, exhausted, already_redeemed, unavailable). A sign-in of a known identity ignores it.