Choose the ways to sign in
Turn a brand's built-in ways to sign in on or off, and let one app take only some of them, such as GitHub and Google.
Every brand offers its built-in ways to sign in until you turn them off: an emailed code or link, a password, a passkey and a Solana wallet. Its upstream providers, such as Google and GitHub, are off until you turn them on. Each app takes every way its brand offers, unless you give it a shorter list.
Both settings hold on Synq's side, wherever someone signs in. A way that a brand or an app doesn't take:
- is left off the hosted page, and its own route answers 404;
- signs nobody up and nobody in, and nobody adds it to their account with it (a link request answers
sign_in_method_unavailable); - is refused on an app's own screens, which hand over with
method_unavailable.
A brand's built-in ways
Change the brand with built_in_methods, naming each way to change. The ways you leave out stay as they are:
{ "built_in_methods": { "email": false, "password": false, "passkey": false, "wallet": false } }In the dashboard, it's Built-in ways under the brand's Sign-in methods. A brand session made with a way you turn off signs nobody in to the brand's apps any more: the person signs in again another way, on a page that says why. The audit log records each change as brand.updated, with built_in_methods_off before and after.
The ways one app takes
Make or change the app with sign_in_methods, a list of method ids:
{ "sign_in_methods": ["github", "google"] }The ids are the built-in ways (email, password, passkey, wallet) and the providers (google, github, microsoft, apple, facebook, x, discord, telegram, matrica). The app takes the ways on its list that the brand also offers. null takes every way the brand offers again. A machine app signs no one in, so it has no list. In the dashboard, it's Ways to sign in on the app's page.
A brand session made another way doesn't sign anyone in to the app. Someone signed in to the brand with a password, say, who opens an app that takes GitHub and Google alone, signs in again with one of those first, on a page that says why. With prompt=none, the app gets login_required.
Tying each person to GitHub or Google
An app that needs to know which GitHub or Google account each person is, such as a free service that limits each person, takes those two alone. Turn the built-in ways off for its brand, turn GitHub and Google on, and give the app ["github", "google"]. Every sign-in to it then comes from one of those accounts. Someone who links both to one account is still one person, with one sub. Ask for the linked_accounts scope to learn which accounts they are, with a GitHub account's age and Google's email_verified, and give your API identity_claims to have the same in its access tokens and API key checks (Linked accounts).
To test rules like these without real accounts, turn on test sign-ins for a test app: it signs in as a made-up GitHub or Google account of the age and kind your test names, everywhere but production.
From an MCP host or an agent, set_sign_in_method turns a built-in way on or off, and set_app_sign_in_methods sets an app's list (MCP tools).