OpenID Connect sign-in

What you supply

You add a provider in the console, from the CLI or in your config file. A sign-in needs the provider's discovery URL, your client ID and a redirect URI, and it is refused if any of the three is missing. A client secret is optional, and the requested scopes default to openid email.

Fóir keeps no catalogue of named providers. Each one you add has a key, a display name and a priority that orders the buttons.

What Fóir does

Fóir reads the provider's discovery document, generates the PKCE pair and the state value, and returns the provider's authorisation URL. When the user comes back, it exchanges the code, verifies the ID token and reads the email address and the provider's stable subject identifier.

How a person is matched to an account

A returning user is matched on the subject identifier, so a changed email address at the provider still resolves to the same account. A first sign-in with an unknown email creates an account with no password, subject to the project's sign-up mode and your plan's active-user limit.

When the email matches an existing account, the provider is attached only if that account has no password and the provider verified the email. Otherwise the sign-in is refused with a message telling the user to sign in with their existing method.

Where the buttons appear

The hosted sign-in page shows a button for each enabled provider. In your own interface, the authProviders query lists them and two mutations start and complete the sign-in, returning the same tokens as every other method.

Hiding a provider or turning it off

A sign-in app can hide a provider for itself. Turning one off for the whole project takes effect at the next release, or at once with foir push --publish.