Skip to main content
Before your users can sign in with useOAuthSignIn, each provider has to be configured once in two places: the provider’s own developer console (where you register your app and get credentials) and the Sublay dashboard (where you paste those credentials in). This page explains the parts that are identical for every provider. The per-provider pages then walk you through each console step by step.
This page covers the one-time setup. For the runtime code — the sign-in button, the callback page, linking and unlinking identities — see OAuth.

​
The redirect chain

The single most important thing to understand is that there are two different redirect URLs, and mixing them up is the most common reason setup fails. When a user signs in, the browser hops through three places:
  1. Your app hands off to the provider’s authorization page.
  2. The provider sends the user back to Sublay — never straight back to you.
  3. Sublay processes the result and redirects to your app with tokens in the URL fragment.
That means:

​
The Sublay callback URL

Every provider console asks for a callback / redirect / return URL. For all four providers it is the same value:
Register that exact string in the provider’s console. It is Sublay’s endpoint, not yours — the provider talks to Sublay, and Sublay forwards the user to your app afterward.

​
Step 1 — Register your app with the provider

Each provider hands you a Client ID and, for most providers, a Client Secret. Pick your provider and follow its walkthrough:

Apple

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

Google

OAuth 2.0 client in the Google Cloud Console.

GitHub

A GitHub OAuth App with a client ID and secret.

Facebook

A Facebook app with Facebook Login enabled.

​
Step 2 — Configure the provider in the Sublay dashboard

In your project dashboard, open Settings → OAuth Providers, click Add Provider, choose the provider, and fill in the modal. For Google, GitHub, and Facebook the fields are: Apple is the exception. Apple has no static client secret — Sublay generates one on the fly by signing a token with your key. So the Apple modal replaces “Client Secret” with Team ID, Key ID, and Private Key (.p8 contents). See the Apple page for exactly what goes where.

​
Allowed Redirect URIs

This field is your app’s return address — the same value you pass as redirectAfterAuth when you call initiateOAuth in code. Sublay only redirects back to URLs on this list, so it must match what your app sends exactly, character for character (a trailing slash mismatch will fail). Add every URL you’ll use — production, staging, local development, and any deep links:
  • Web — a full HTTPS URL, e.g. https://yourapp.com/auth/callback
  • Expo / native — your custom-scheme deep link, e.g. myapp://auth/callback
Each entry must be a valid URL. For local web development, http://localhost:3000/auth/callback is fine.

​
Scopes

Scopes control what profile data the provider returns. Sublay pre-fills each provider with the defaults it needs to create a user (name and email in most cases), so you can leave them untouched for a standard setup. Add more only if your provider requires additional scopes for data you specifically need.

​
Step 3 — Enable and test

Saving the provider enables it. Wire up the sign-in button as shown in OAuth and run the flow end to end. If something fails, the two usual culprits are:
  1. A redirect URI mismatch — the value in your code, the Allowed Redirect URIs list, and (on the provider side) the registered callback URL must all agree.
  2. A missing provider callback — confirm https://api.sublay.io/v7/oauth/callback is registered in the provider’s console.

​
See Also