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](https://console.authdog.com):

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:

```url
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:

| Situation | Callback host |
| --- | --- |
| Default | `https://identity.authdog.com` |
| Environment with a live [custom domain](/docs/custom-domains) | `https://auth.yourdomain.com` |
| Local development | `http://localhost:3500` |

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.

> **Caution**
>
> Most providers match redirect URIs exactly: scheme, host, path, and trailing
> slash. A mismatch surfaces as the provider's own error page — `redirect_uri_mismatch`,
> `invalid_redirect_uri` — before the user ever returns to Authdog.

## 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:

```url
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:

| Connector | Provider ID | Connector | Provider ID |
| --- | --- | --- | --- |
| Apple | `apple-oauth20` | Figma | `figma-oauth20` |
| Google | `google-oauth20` | Fitbit | `fitbit-oauth20` |
| Meta (Facebook) | `facebook-oauth20` | FreshBooks | `freshbooks-oauth20` |
| Microsoft | `microsoft-oauth20` | Hugging Face | `huggingface-oauth20` |
| GitHub | `github-oauth20` | IBMid | `ibmid-oauth20` |
| GitLab | `gitlab-oauth20` | ID.me | `idme-oauth20` |
| LinkedIn | `linkedin-oauth20` | ID.me Community | `idme-community-oauth20` |
| Discord | `discord-oauth20` | IDPartner | `idpartner-oauth20` |
| Slack | `slack-oauth20` | Indeed | `indeed-oauth20` |
| X (Twitter) | `twitter-oauth20` | Intuit | `intuit-oauth20` |
| TikTok | `tiktok-oauth20` | Kakao | `kakao-oauth20` |
| Spotify | `spotify-oauth20` | Keycloak | `keycloak-oauth20` |
| Twitch | `twitch-oauth20` | Klarna | `klarna-oauth20` |
| Amazon | `amazon-oauth20` | LINE | `line-oauth20` |
| Asignio | `asignio-oauth20` | NAVER | `naver-oauth20` |
| AWS Cognito | `aws-cognito-oauth20` | PayPal | `paypal-oauth20` |
| Badge | `badge-oauth20` | PayPal Sandbox | `paypal_sb-oauth20` |
| Baidu | `baidu-oauth20` | Planning Center | `planning-center-oauth20` |
| Basecamp | `basecamp-oauth20` | Renren | `renren-oauth20` |
| BitBadges | `bitbadges-oauth20` | Salesforce | `salesforce-oauth20` |
| Bitbucket | `bitbucket-oauth20` | Salesforce Sandbox | `salesforce_sb-oauth20` |
| 1Kosmos BlockID | `blockid-oauth20` | Salesforce Community | `salesforce_community-oauth20` |
| Box | `box-oauth20` | Shopify | `shopify-oauth20` |
| Coinbase | `coinbase-oauth20` | Vercel | `vercel-oauth20` |
| d ACCOUNT | `daccount-oauth20` | Vimeo | `vimeo-oauth20` |
| DigitalOcean | `digitalocean-oauth20` | VKontakte | `vk-oauth20` |
| Dock Web3 ID | `dock-web3id-oauth20` | Weibo | `weibo-oauth20` |
| DocuSign | `docusign-oauth20` | WordPress.com | `wordpress-oauth20` |
| Dribbble | `dribbble-oauth20` | Xero | `xero-oauth20` |
| Dropbox | `dropbox-oauth20` | Yahoo | `yahoo-oauth20` |
| Dwolla | `dwolla-oauth20` | Yammer | `yammer-oauth20` |
| Exact Online | `exact-oauth20` | Yandex | `yandex-oauth20` |

## 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.

> **Note**
>
> Connectors cover consumer and developer identity. For workforce identity —
> Okta, Entra ID, JumpCloud, Ping, BeyondTrust, generic SAML and OIDC — use
> [Enterprise SSO](/docs/sso), which adds email-domain routing so a user's
> address selects their employer's connection.

## 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](/docs/users) for how identities appear on the user record.

## Related

| Read | To learn how to |
| --- | --- |
| [Authentication (console)](/docs/console/authentication) | Configure every sign-in method for an environment |
| [Enterprise SSO](/docs/sso) | Connect workforce identity providers with SAML and OIDC |
| [Custom domains](/docs/custom-domains) | Serve authentication — and callbacks — from your own host |
| [Branding](/docs/console/branding) | Style the hosted page these buttons appear on |
| [Users](/docs/users) | Inspect linked identities on a user record |