Overview

Connectors are the external identity providers your users sign in with — Apple, Google, Meta, Microsoft, GitHub, and sixty more. Authdog handles the OAuth 2.0 exchange, normalizes the profile it gets back, and links it to an Authdog user, so your application only ever deals with an Authdog session.

Every connector is configured per environment. Development, staging, and production each hold their own client credentials and their own callback URL, and enabling a provider in one environment never affects another.

How a connector works

1. A user picks the provider on your sign-in page (hosted or your own UI).
2. Authdog redirects to the provider's authorization endpoint with the client ID and scopes for that connection.
3. The user authenticates and consents at the provider.
4. The provider redirects back to Authdog's callback URL with an authorization code.
5. Authdog exchanges the code for tokens, reads the profile, and creates or links the Authdog user.
6. Your application receives an Authdog session, exactly as it would after a password or passkey sign-in.

Your code never handles the provider's tokens. It reads the Authdog session, and provider identity arrives as a linked identity on the user.

Set up any connector

The steps are the same for every provider. Only the developer console you visit and the fields you copy differ.

1. Create an OAuth application in the provider's developer console.
2. Copy the redirect URI Authdog shows you into that application's list of allowed redirect URIs.
3. Paste the provider's client ID and client secret into Authdog.
4. Activate the connection and test a sign-in.

In the Authdog console:

1. Select the project and environment.
2. Open Authentication > Providers.
3. Filter to OAuth 2.0 and find the provider in the catalog.
4. Click Enable.
5. Copy the Redirect URI shown in the form.
6. Enter the provider's credentials.
7. Save, then toggle the connection active.

The redirect URI

Authdog's callback endpoint is bound to the individual connection, not to the provider:

https://identity.authdog.com/api/v1/callback/<connectionId>

The connection form displays the exact string with a copy button — use that value rather than assembling it by hand. Three things change it:

Because connectionId is unique per connection, the same provider configured in two environments produces two different redirect URIs. Register both in the provider's application, or create a separate provider application per environment — which is the better practice, since it also keeps credentials separated.

Starting a sign-in

With the hosted sign-in page, every active connection renders as a button automatically. Nothing to wire up.

From your own UI, link to the connection's sign-in endpoint:

https://identity.authdog.com/api/v1/signin/<connectionId>

You can pass login_hint to pre-fill the account, and the endpoint honors the sign-up and return-URL context Authdog carries through the flow.

Provider guides

Every connector in the console catalog has its own guide — linked from the cards at the foot of this page and from the sidebar. They share the redirect-URI step above; each guide covers where the credentials come from and what the provider actually returns.

The provider ID is what the connection row stores, and what the console shows on the connection:

Connectors that need a Domain URI

Some providers run on a host that belongs to you or your customer rather than a fixed one, so the connection form asks for a Domain URI alongside the credentials: a Cognito user pool domain, a Shopify store, a Keycloak realm, a Salesforce Experience Cloud site, or a Klarna regional login host.

Authdog substitutes that value into the provider's endpoints for AWS Cognito, Salesforce Community, Shopify, Klarna, and Keycloak. Other catalog entries that accept the field — Exact Online, 1Kosmos BlockID, Asignio, Badge, BitBadges, Dock Web3 ID, and IDPartner — are not covered by that substitution on both legs of the flow, so test them end to end in a development environment before rolling them out.

Account linking

When a provider returns an email address that already belongs to an Authdog user, the provider identity links to that account rather than creating a second one. Providers that do not release an email — or where the user hides it, as with Apple's private relay — produce an account keyed on the provider's stable subject identifier.

Decide early which providers you trust to assert an email, and keep that consistent across environments. See Users for how identities appear on the user record.

Related