Sign in with Apple lets users authenticate with the Apple ID already on their iPhone, iPad, or Mac. It is the only connector that does not use a static client secret: Apple requires a short-lived signed JWT, which Authdog mints for every token exchange from the key material you provide.

Apple also requires it. If your iOS app offers any other social login, App Store review expects Sign in with Apple alongside it.

## Before you start

You need a paid [Apple Developer Program](https://developer.apple.com/programs/) membership. The free account cannot create the Services ID or the key this connector depends on.

## Copy the redirect URI

In the [Authdog console](https://console.authdog.com), select the project and environment, open **Authentication > Providers**, find **Apple**, and click **Enable**. The form shows the redirect URI for this connection:

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

Keep that dialog open — Apple needs this value, and you need Apple's values to finish it.

> **Caution**
>
> Apple rejects `http://` and bare hostnames. `localhost` cannot be registered
> at all, so local development against Apple needs a public HTTPS host (a tunnel,
> or an environment with a [custom domain](/docs/custom-domains)).

## Create the App ID

1. Open [Certificates, Identifiers & Profiles](https://developer.apple.com/account/resources/identifiers/list).
2. Select **Identifiers**, then **+**.
3. Choose **App IDs**, then **App**.
4. Give it a description and a bundle ID (for example `com.example.app`).
5. Under **Capabilities**, enable **Sign In with Apple**.
6. Register.

## Create the Services ID

The Services ID is the web client — it becomes the `client_id` Apple sees.

1. Back in **Identifiers**, select **+**, then **Services IDs**.
2. Enter a description and an identifier (for example `com.example.app.web`). Note it down.
3. Register, then reopen the Services ID.
4. Enable **Sign In with Apple** and select **Configure**.
5. Set **Primary App ID** to the App ID you just created.
6. Under **Domains and Subdomains**, add `identity.authdog.com` — or your custom domain host.
7. Under **Return URLs**, paste the redirect URI from Authdog.
8. Save, then **Continue** and **Save** on the Services ID.

## Create the sign-in key

1. Open **Keys** and select **+**.
2. Name the key, enable **Sign In with Apple**, and **Configure** it against the primary App ID.
3. Register, then **Download** the `.p8` file. Apple lets you download it exactly once.
4. Note the **Key ID** shown on the key's page.

Your **Team ID** is in the top-right of the developer portal, and on the membership details page.

## Configure Authdog

Return to the connection form and fill in:

| Field | Value |
| --- | --- |
| **Team ID** | The 10-character team identifier from your developer account |
| **Service ID** | The Services ID identifier, e.g. `com.example.app.web` |
| **Key ID** | The 10-character identifier of the sign-in key |
| **Private Key** | The full contents of the downloaded `.p8` file |

Paste the private key including its header and footer lines:

```text
-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQg...
-----END PRIVATE KEY-----
```

Save the connection, then toggle it **active**.

Authdog signs a client-secret JWT with ES256 using this key for each token request, so there is no secret to rotate on a schedule — but the key itself is a credential. Store the `.p8` in [Vault](/docs/console/vault) or your own secret manager; Apple will not give you a second copy.

## What Apple returns

Authdog requests the `openid email name` scopes and reads the profile from the `id_token` Apple issues — Apple exposes no userinfo endpoint.

Two Apple behaviours shape the user records you end up with:

- **The name is sent once.** Apple includes the user's name only on the very first authorization, and only if the user agrees to share it. Later sign-ins carry the identifier and email alone. Persist the name when you first see it.
- **The email may be a relay.** Users can choose **Hide My Email**, which yields an address like `a1b2c3@privaterelay.appleid.com` that forwards to their real inbox. It is stable and deliverable, but it is not their public address, and it will not match an existing account created with a different provider.

Apple posts the authorization response back with `response_mode=form_post`, which Authdog's callback endpoint accepts on both `GET` and `POST`.

## Test it

1. Open your environment's hosted sign-in page, or link to `https://identity.authdog.com/api/v1/signin/<connectionId>`.
2. Select **Continue with Apple** and complete the flow.
3. Confirm the new user appears under **Users** in the console with an Apple identity linked.
4. Sign out, sign in again, and confirm you land on the same user rather than a duplicate.

## Troubleshooting

| Symptom | Cause |
| --- | --- |
| `invalid_client` | Team ID, Key ID, or Services ID mismatch; or the key is not enabled for Sign In with Apple |
| `invalid_grant` | The `.p8` contents are truncated or reformatted — repaste the whole file |
| Apple's "redirect_uri" error page | The Return URL in the Services ID does not match Authdog's redirect URI exactly |
| Domain verification prompt | The domain under **Domains and Subdomains** is missing or misspelled |

## Related

| Read | To learn how to |
| --- | --- |
| [Connectors](/docs/connectors) | Set up any other social provider |
| [Google](/docs/connectors/google) | Add the other half of most consumer sign-in pages |
| [Vault](/docs/console/vault) | Store the `.p8` key alongside your other secrets |
| [Custom domains](/docs/custom-domains) | Serve the callback from your own HTTPS host |