Set up your
sign-in providers.

Flow

OpenID Connect · Authorization code

Credentials to save

Client ID and client secret

Sign-in scopes

openidprofileemail

Registration steps

1. Create or select a Google Cloud project. Open Google Auth Platform and configure Branding with AnyOAuth’s name, support email, homepage, privacy policy, and authorized domains.
2. Choose the Audience. For a public service, use External; while testing, add the accounts that should be able to sign in.
3. Under Clients, create an OAuth client with application type Web application. Add the callback below under Authorized redirect URIs, matching the full URL exactly.
4. Save the client ID and client secret. Request only openid, profile, and email in the authorization flow; do not request offline access.
5. Test a complete login, then complete the console’s publishing and branding requirements before opening access to the public.

Implementation note. Google and GitHub are implemented, but require operator credentials before sign-in is available. A backend redirect flow does not need the JavaScript sign-in widget.

Flow

OAuth 2.0 · Authorization code

Credentials to save

Client ID and client secret

Sign-in scopes

read:useruser:email

Registration steps

1. Open Settings → Developer settings → OAuth Apps → New OAuth App. Register under the service’s owner account or organization.
2. Enter AnyOAuth as the application name and https://anyoauth.com as the homepage. Enter the callback below as an Authorization callback URL.
3. Register the application, record the client ID, and generate a client secret.
4. Request read:user and user:email. Use the user ID as the provider subject and retrieve primary email information from the authenticated email endpoint.
5. Test with both a public-email account and a private-email account. Use separate registrations for development and production if you want isolated credentials.

Implementation note. Do not request repository scopes for sign-in. Email may be missing; a username is not a stable account identifier.

Flow

OpenID Connect · Authorization code

Credentials to save

Application (client) ID, tenant configuration, and secret value

Sign-in scopes

openidprofileemail

Registration steps

1. In Microsoft Entra admin center, choose the tenant that will own the registration. Open Entra ID → App registrations → New registration.
2. For broad coverage, select the account type that includes any Entra ID tenant and personal Microsoft accounts. Choose a narrower audience if the product requires it.
3. Add a Web platform redirect URI using the proposed callback below. Save the registration and record its Application (client) ID.
4. Under Certificates & secrets, create a client secret and capture the secret value, not its ID. Record its expiration date.
5. Use the matching tenant authority, commonly /common for the broad account audience. Request openid, profile, and email, and validate the returned issuer for the tenant that signed in.

Implementation note. Email and profile fields are not guaranteed. Graph User.Read is a separate permission if the future adapter needs Graph; basic OIDC sign-in should not assume it needs calendar or directory access.

Flow

OpenID Connect · Authorization code

Credentials to save

Services ID, Team ID, Key ID, and Sign in with Apple private key (.p8)

Sign-in scopes

nameemail

Registration steps

1. Use an Apple Developer Program account. Create or select a primary App ID and enable Sign in with Apple.
2. Create a Services ID for web authentication. Enable Sign in with Apple on that Services ID and associate it with the primary App ID.
3. Configure the website domain and the exact HTTPS return URL below. Use a real HTTPS development domain or tunnel rather than localhost.
4. Create a Sign in with Apple private key associated with the primary App ID. Record the Team ID and Key ID and download the .p8 key.
5. The future backend adapter must generate Apple’s signed client-secret JWT and handle the form_post callback when requesting name and email. Preserve first-authorization name data.

Implementation note. The Services ID is the web client ID. Users can choose a private relay email, and the name is normally supplied only during the first authorization. Apple uses name/email request scopes rather than Google’s profile scope.

Flow

OAuth 2.0 · Authorization code

Credentials to save

App ID and app secret

Sign-in scopes

public_profileemail

Registration steps

1. Open Meta for Developers → My Apps → Create App. Choose the consumer Facebook Login use case offered by the current creation flow.
2. Configure the app’s basic settings with its domain, website URL, contact details, privacy-policy URL, and user-data deletion instructions or callback.
3. Open the Facebook Login settings and add the proposed callback below to Valid OAuth Redirect URIs. Enable the web login flow as required by the console.
4. Record the App ID and app secret. Limit sign-in permissions to public_profile and email and select the Graph API version for the adapter.
5. Test with accounts assigned app roles in development mode. Before launch, complete the access, review, or business-verification requirements shown for this app, then enable live access.

Implementation note. Email is not guaranteed. Meta’s documentation could not be fetched during preparation, so confirm current console labels and permission requirements in the official links before registration.

Flow

OAuth 2.0 · Authorization code

Credentials to save

Client ID and client secret (not the bot token)

Sign-in scopes

identifyemail

Registration steps

1. Open the Discord Developer Portal and create a New Application owned by the service’s account or team.
2. Open OAuth2, record the client ID, and obtain the client secret.
3. Add the proposed callback below to the application’s Redirects and save the changes.
4. Use the authorization-code flow with identify and email. Exchange the code using an application/x-www-form-urlencoded token request.
5. Fetch /users/@me with the access token and map its stable ID, display name, avatar, email, and verified flag into the normalized profile.

Implementation note. A bot installation is not needed for sign-in. Do not add bot, guilds, or message permissions to an identity-only flow.

Flow

OpenID Connect · Authorization code

Credentials to save

Client ID and client secret

Sign-in scopes

openidprofileemail

Registration steps

1. Create an app in LinkedIn’s Developer Portal and supply the required app details, company-page association, logo, and privacy policy.
2. Open Products and request Sign In with LinkedIn using OpenID Connect. Complete any app/page verification requested by the portal.
3. Under Auth, add the proposed callback below to Authorized redirect URLs and record the client ID and client secret.
4. Once the product is provisioned, request openid, profile, and email in an authorization-code flow.
5. Validate the ID token using LinkedIn’s OIDC metadata; use its userinfo endpoint when needed. Handle missing email and email_verified claims.

Implementation note. Use the current OIDC product rather than legacy r_liteprofile/r_emailaddress scopes. LinkedIn sign-in is not real-world identity verification.

Flow

OpenID Connect · Authorization code

Credentials to save

Application ID and secret

Sign-in scopes

openidprofileemail

Registration steps

1. On GitLab.com, open Edit profile → Access → Applications → Add new application. A group-owned application is also available under group Settings → Applications.
2. Name the application and register the proposed callback below as its Redirect URI.
3. For a server-side OIDC adapter, use a confidential application and select openid, profile, and email.
4. Save the application and capture the Application ID and secret. The secret is shown at creation; renewing it invalidates the previous credential.
5. Build against GitLab.com first. Validate OIDC claims and use the stable subject; treat self-hosted GitLab instances as separate issuers and registrations.

Implementation note. Avoid api and repository permissions for sign-in. If choosing a plain OAuth profile adapter instead of OIDC, read_user is the alternative profile scope, not an extra requirement for this OIDC plan.

Flow

OpenID Connect · Authorization code

Credentials to save

Client ID and client secret from Basic Information

Sign-in scopes

openidprofileemail

Registration steps

1. Create a Slack app and select a development workspace. Give it the service’s user-facing name.
2. Open OAuth & Permissions and add the proposed callback below as a Redirect URL. For local work, register an HTTPS tunnel URL.
3. Record the client ID and client secret under Basic Information.
4. Use Sign in with Slack’s OpenID flow with openid, profile, and email. Authorize at /openid/connect/authorize and exchange codes at /api/openid.connect.token.
5. Validate the ID token and nonce and normalize workspace/user identity. Configure distribution for other workspaces and test outside the development workspace before launch.

Implementation note. Do not combine sign-in scopes with bot or workspace API scopes in one flow. The legacy identity.* scopes and normal app-install OAuth endpoints are not the modern sign-in flow.

Flow

OAuth 2.0 · Authorization code

Credentials to save

Client ID and client secret

Sign-in scopes

user:read:email

Registration steps

1. Verify the owner’s Twitch email and enable two-factor authentication. Open the Developer Console → Applications → Register Your Application.
2. Choose a unique application name, add the proposed callback below to OAuth Redirect URLs, and select the relevant application category.
3. For the backend authorization-code flow, select a confidential client type if the console asks. Create the application.
4. Open Manage, record the client ID, and generate a New Secret. Generating another secret invalidates the existing one.
5. Use authorization-code sign-in with user:read:email and fetch the authenticated user through the Helix Users endpoint. Supply both the bearer token and Client-Id header.

Implementation note. This plan uses OAuth plus the user profile API. Do not add chat, moderation, or channel-management scopes. Keep email nullable.

Connect to AnyOAuth

Google and GitHub use the configuration already present in api/wrangler.jsonc. The other eight need adapters, contract changes, and configuration bindings before their registrations can be used.

1. Set the deployed API’s API_ORIGIN to match the origin above and set DASHBOARD_ORIGIN to the dashboard’s actual address. Replace the production .example placeholders.
2. Set GOOGLE_CLIENT_ID and/or GITHUB_CLIENT_ID in the production environment’s vars.
3. From api/, install the corresponding client secrets through Wrangler’s prompts:

npx wrangler secret put GOOGLE_CLIENT_SECRET --env production
npx wrangler secret put GITHUB_CLIENT_SECRET --env production

For development, use the local API origin and inject secrets from your secret manager as described in the repository README. Keep secrets out of this guide and frontend bundles.

Verify the completed flow

• The provider shows the correct AnyOAuth app name and identity-only permissions.
• The callback lands on the API’s exact registered URL.
• Code exchange succeeds and returns an AnyOAuth profile token.
• The profile has a stable subject, including when email or name is missing.
• Canceling login returns a useful error and allows retry.

Suggested next adapters: Microsoft and Apple, then Discord and Facebook according to customer demand. Registering an app alone does not enable that provider in AnyOAuth.