Set up OAuth providers

Let people sign in with accounts they already have, such as GitHub or Google, instead of creating another password. Social sign-in works for both portal users (your customers) and team members. This article covers the supported providers, how to set up GitHub and Google, and how to fix common errors.

Supported providers

Every provider works for portal users and team members. You configure a provider once and turn it on with a single toggle, which adds it to both the portal sign-in form and the team sign-in form. Social providers are off until you turn them on.

For team-wide single sign-on with verified domains and enforcement, see Set up single sign-on. For a custom OIDC button on the portal sign-in form, see Control portal access and sign-in.

How it works

1. The person clicks Continue with the provider.
2. A window opens the provider's sign-in page.
3. They sign in and grant permission.
4. The provider redirects back to Quackback with an authorization code.
5. Quackback exchanges the code for the person's profile and email.
6. Quackback creates their session.

The callback URL

Every provider needs a callback URL (also called a redirect URI) in this form:

https://YOUR_DOMAIN/api/auth/callback/PROVIDER_ID

YOUR_DOMAIN is the domain people use to reach your Quackback workspace. PROVIDER_ID is one of: apple, discord, facebook, github, gitlab, google, linkedin, microsoft, reddit, twitter.

For example: https://feedback.yourcompany.com/api/auth/callback/github.

Set up GitHub

Step 1: Create an OAuth app on GitHub

1. Go to GitHub Developer Settings.
2. Click OAuth Apps, then New OAuth App.
3. Fill in the details shown in the table below.
4. Click Register application.
5. Copy the Client ID.
6. Click Generate a new client secret and store it safely.

Step 2: Add the credentials in Quackback

1. Go to Admin > Settings > Access & Security and open the Sign-in tab.
2. In the Social sign-in card, find GitHub and click Configure.
3. Paste the Client ID and Client Secret, then save.
4. Turn GitHub on.

Set up Google

Step 1: Create OAuth credentials in Google Cloud

1. Go to the Google Cloud Console.
2. Create a project or select an existing one.
3. Go to APIs & Services, then Credentials.
4. Click Create Credentials, then OAuth client ID.

5. If prompted, configure the OAuth consent screen first:

   • User type: External (or Internal for a Google Workspace organization)
   • App name: Quackback
   • User support email: your email
   • Authorized domains: yourcompany.com

Step 2: Configure the OAuth client

1. Application type: Web application.
2. Name: Quackback.
3. Authorized JavaScript origins: https://feedback.yourcompany.com
4. Authorized redirect URIs: https://feedback.yourcompany.com/api/auth/callback/google
5. Click Create.
6. Copy the Client ID and Client Secret.

Step 3: Add the credentials in Quackback

1. Go to Admin > Settings > Access & Security and open the Sign-in tab.
2. In the Social sign-in card, find Google and click Configure.
3. Paste the Client ID and Client Secret, then save.
4. Turn Google on.

Other providers

Every other provider follows the same pattern:

1. Create an OAuth application in the provider's developer console.
2. Set the callback URL to https://YOUR_DOMAIN/api/auth/callback/PROVIDER_ID.
3. Enter the Client ID and Client Secret under Admin > Settings > Access & Security > Sign-in > Social sign-in, then turn the provider on.

A provider only appears on the sign-in page once its credentials are saved and its toggle is on. Its toggle stays locked off until you save a Client ID and Client Secret.

Credentials are stored encrypted in Quackback. You don't set them as environment variables.

Common issues

Callback URL mismatch

The callback URL in your provider's app must match exactly. Check for:

• http versus https
• A trailing slash
• A missing or wrong port number
• A different domain or subdomain

Invalid client ID or client secret

1. Check that you copied the values exactly, with no extra spaces.
2. Make sure the OAuth app hasn't been deleted or disabled.
3. For Google, check whether the consent screen is still in testing mode.

Popup blocked

Social sign-in opens the provider in a popup window. If the browser blocks it, allow popups for your Quackback domain and try again.

"Access denied" or "Application not authorized"

• GitHub: check that the OAuth app isn't suspended, and review your organization's access policies.
• Google: if the consent screen is in testing mode, add test users, or submit the app for verification for production use. Check whether domain restrictions apply.

"Unable to get email from provider"

Quackback needs an email address from the provider.

• GitHub: the person needs a public email or must grant email access. Quackback also checks their verified email list.
• Google: the email scope is always requested.

The sign-in redirects to the wrong address (self-hosted)

If you self-host, make sure BASE_URL matches the public address of your instance, and that your reverse proxy passes the original host and protocol headers. See Set up a reverse proxy.

Security best practices

• Protect client secrets. Rotate them from time to time and update them with Configure on each provider.
• Use separate OAuth apps for testing and production, so leaking one set doesn't expose the other.
• Use HTTPS callback URLs on your exact domain. Don't use wildcards.
• Turn off providers you don't use.

Quackback only requests basic profile information and the email address. It never asks for write access to the person's account.

Related articles

• Set up single sign-on
• Set up magic-link sign-in
• How sign-in works
• Self-hosting FAQ