Hosted sign-in

What the page offers

The page shows a button for each identity provider you have configured, a password tab and an email code tab. Password sign-in is on by default. The six-digit emailed code stays off until you turn on customerOtpEnabled in the project's settings. (The docs call your users "customers".)

Each application you register for sign-in (a "relying party" in the docs) can hide a method or a provider for itself. It can narrow what the project allows and never widen it.

Your domain and your branding

The page is served from auth.foir.io until you list a login domain on the sign-in app and verify it with two DNS records. The name, logo and primary colour belong to the project, so every app in a project shares one look. An organisation can override them, and the page follows.

New accounts and password resets

On the hosted page a new person gets an account by entering a code sent to an address nobody has used, or by a first sign-in through a provider. Registering with a password is the customerRegister mutation and resetting one is a pair of mutations, all called from your own interface.

A project setting decides who may sign up: anyone, invited people only, a waitlist, or nobody. Existing users can always sign in.

Tokens and sessions

A sign-in is an OAuth 2.1 authorisation code flow with PKCE. It returns a 15-minute access token and a 30-day refresh token that rotates on every use. Replaying a token that has already been rotated revokes the whole family.

On a verified login domain that shares a registrable domain with your app, Fóir sets a session cookie that your app exchanges for access tokens, so no token is stored in the browser. That session ends after 30 idle days or 90 days from first sign-in, and both can be set per project.