Home
Sign in

People can sign in to this zone with their Google, Microsoft or GitHub account instead of a password. Each provider you switch on adds a Continue with … button to the login and signup pages. Nothing changes until you switch one on: the password form keeps working exactly as before, for everybody.

This page is for zone operators. You set providers up under Zone → Sign-in.

Before you start

The providers send people back to one fixed address, which you register with them in advance. ORC8R builds that address from the zone's web URL (Zone → Settings), so set that first. Until it is set, no button appears. The Sign-in tab then shows the exact redirect URI for each provider:

https://v0.orc8r.com/login/google/callback
https://v0.orc8r.com/login/microsoft/callback
https://v0.orc8r.com/login/github/callback

Register the address exactly as shown. Scheme, host, port and path must all match.

Google

  1. In the Google Cloud Console, pick or create a project. Configure the OAuth consent screen; the openid, email and profile scopes are the only ones needed.
  2. Create credentials → OAuth client ID, application type Web application.
  3. Under Authorized redirect URIs, add the Google redirect URI from the Sign-in tab.
  4. Copy the Client ID and Client secret into the Google fields on the Sign-in tab, set Enable Google to true and save.

To admit only your company's Google Workspace accounts, put its domain (for example example.com) in Google allowed domain. Consumer Gmail accounts and other Workspace domains are then refused.

Microsoft

  1. In the Microsoft Entra admin center, open App registrations → New registration.
  2. Under Supported account types, choose who may sign in. Then set Microsoft tenant on the Sign-in tab to match:
    • common: work, school and personal Microsoft accounts;
    • organizations: work and school accounts from any directory;
    • consumers: personal Microsoft accounts only;
    • your Directory (tenant) ID: accounts from your own directory only.
  3. Add a Web platform redirect URI: the Microsoft redirect URI from the Sign-in tab.
  4. Under Certificates & secrets, create a client secret. Copy its Value, not its ID.
  5. Under Token configuration → Add optional claim → ID, add email and xms_edov. Without xms_edov nobody can sign in with Microsoft; see How accounts are matched below.
  6. Copy the Application (client) ID and the secret value into the Microsoft fields, set Enable Microsoft to true and save.

GitHub

  1. Under GitHub → Settings → Developer settings → OAuth Apps, click New OAuth App. For an organization, use the organization's settings instead.
  2. Set Authorization callback URL to the GitHub redirect URI from the Sign-in tab. An OAuth App has one callback URL, so each zone needs its own app.
  3. Generate a client secret. Copy the Client ID and the secret into the GitHub fields, set Enable GitHub to true and save.

Testing the setup

Test connection on the Sign-in tab sends each enabled provider a made-up sign-in code, using the stored client ID and secret. The provider checks the credentials before it looks at the code, so its answer tells you whether it accepted them. It does not sign anybody in. To try the whole flow, sign out and use the button on the login page.

How accounts are matched

When somebody comes back from a provider, ORC8R decides who they are in this order:

  1. They have signed in with this provider before. They get the same account again, even if their email address has changed since.

  2. The provider vouches for an email address an existing account uses. The provider is linked to that account and they are signed in. If that account never confirmed its email address, anybody could have created it by typing the address. So before the real owner is let in, ORC8R takes the account back: the address is marked confirmed, its password is replaced with one nobody knows, which ends every session, and all its API keys are deleted. The owner can set a new password through Forgot password?. Zone operators are the exception: their accounts were set up during onboarding rather than by signing up, so theirs are linked and marked confirmed but never reset.

    If the account is already connected to a different account at the same provider, the sign-in is refused instead. That is what happens when a company hands an old address to a new employee: the newcomer must not walk into the previous holder's account.

  3. No account uses the address. If the zone allows public registration, a new account is created with the address already confirmed. It gets no password, so the provider is the way in until the owner sets one. If registration is closed, the sign-in is refused.

An email address only counts when the provider vouches for it:

  • Google must mark the address verified.
  • Microsoft puts whatever address a directory administrator typed in the email claim. It only counts when the xms_edov claim says the directory has verified the address's domain. Without that claim the sign-in is refused, and the person is asked to use their password.
  • GitHub uses the account's primary address, and only if GitHub has verified it. An account without a verified primary address is refused.

A browser that is already signed in as somebody else is refused. Sign out first.

Rolling out

On a zone with several servers, upgrade every server before you enable a provider. A server running an older release does not know the new sign-in pages, and a visitor load-balanced onto it would get not found halfway through the redirect.