Social sign-in

Your users can sign in with an account they already have. You register an application with each provider and give Base316 its credentials; Base316 runs the flow on your behalf and hands your application the same single-use code a password sign-in does.

Set providers up per environment, on the project's Sign-in page design screen, in the Social sign-in card. Choose Set up beside a provider, register the Callback URL the dialog shows, then paste the client ID and secret. The same is available over the API with a secret key: PUT /v1/auth-config/providers/{provider}, or authConfig.saveProvider in the SDK.

The callback URL

Every provider has one callback URL, the same for every environment and every customer:

{BASE316_AUTH_URL}/hosted/oauth/{slug}/callback

On the hosted service that is https://api.base316.com/hosted/oauth/{slug}/callback. The dialog shows the exact value for your deployment — copy it from there. Register it exactly; providers compare it character for character.

Which accounts are joined by email

Every account is found by the provider's own permanent id for it, never by email, so somebody who changes their address at the provider keeps their account here.

The first time somebody signs in with a provider, Base316 checks whether an account already uses that address. It joins the two only when the provider says the address is verified. Joining on an unverified address would let anyone who can register your user's address at some provider sign in as them. If the address is taken and the provider cannot vouch for it, the sign-in is refused and the person is asked to sign in with their password first.

Some providers cannot vouch for an address at all, so a sign-in with them is never joined to an existing account:

Discord shares an address with a verified flag, and only a verified one is joined. The dialog for each of the three above says so as well.

Provider notes

Discord. Add the callback under OAuth2 → Redirects. Base316 asks for the identify and email scopes.

X. Create the app with OAuth 2.0 turned on and the type set to Web App (a confidential client), then add the callback under User authentication settings. Base316 asks for users.read and tweet.read — X will not grant the first without the second — and authenticates at X's token endpoint with HTTP Basic, as X requires. Paste the OAuth 2.0 client ID and secret, not the API key and secret.

Twitch. Register the callback as the app's OAuth Redirect URL and choose the Confidential client type. Base316 asks for user:read:email.

Roblox. Add the callback as a redirect URL and grant the app the openid and profile scopes. Roblox names change, so the account is tied to the Roblox user id, never to the name.

Restricting Microsoft to certain directories

By default Continue with Microsoft admits work, school and personal accounts alike. In the Microsoft dialog, Account types narrows that:

For the last, enter each directory's tenant ID — a GUID such as 72f988bf-86f1-41af-91ab-2d7cd011db47, found on the directory's Overview page in the Microsoft Entra admin center. A domain name such as contoso.onmicrosoft.com is refused.

The restriction is enforced where it cannot be sidestepped. With one tenant listed, the Microsoft prompt itself only accepts that directory. With several, Microsoft has no single address that accepts exactly those, so the prompt accepts any work account — and Base316 then checks the directory in the token Microsoft returns (tid) against your list on every sign-in, and refuses any other. Every mode is checked this way, not only the last. A refused person sees the same message as any other failed sign-in, so the page never reveals which directories you allow.

Register the Microsoft app as multitenant if you list more than one directory or choose anything but a single one; a single-tenant registration only works for its own directory.

Over the API:

await base316.authConfig.saveProvider("MICROSOFT", {
	clientId: "…",
	tenantMode: "SPECIFIC",
	allowedTenantIds: ["72f988bf-86f1-41af-91ab-2d7cd011db47"],
});

Leaving tenantMode out of a later save keeps the stored restriction, so turning the provider off and on again cannot widen it.