<!--
{
  "availability" : [
    "Sign in with Apple REST API: 1.0.0 -"
  ],
  "documentType" : "symbol",
  "framework" : "signinwithapple",
  "identifier" : "/documentation/SigninwithAppleRESTAPI/Request-an-authorization-to-the-Sign-in-with-Apple-server.",
  "metadataVersion" : "0.1.0",
  "role" : "Web Service Endpoint",
  "symbol" : {
    "kind" : "Web Service Endpoint",
    "modules" : [
      "Sign in with Apple REST API"
    ],
    "preciseIdentifier" : "rest:appleid_signin_server_api:get:auth-authorize"
  },
  "title" : "Request an authorization to the Sign in with Apple server"
}
-->

# Request an authorization to the Sign in with Apple server

Add a Sign in with Apple authorization flow to apps and web services that can’t directly access Sign in with Apple JS.

## Discussion

Use this endpoint to request authorization for your app to receive the user’s information with Sign in with Apple. If your app is contained within an app group, the user credentials are associated with the primary app and shared across the group. To learn more about app groups, visit <doc://com.apple.signinwithapple/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple>.

### Get the user information and tokens

When the Sign in with Apple UI appears in the opened browser tab, the user can sign in and accept any terms and conditions for your app. After Apple processes the authorization request, the handling of the response depends on the value in `response_mode`:

- For the `query` value, the response parameters are added to the `redirect_uri` value as query parameters, and the browser is redirected to the resulting value.
- For the `fragment` value, the response parameters are added to the `redirect_uri` value as a fragment, and the browser is redirected.
- For the `form_post` value, an HTTP POST request containing the results of the authorization is sent to the `redirectURI`. The HTTP body contains the result parameters with `application/x-www-form-urlencoded` content type.

A successful response contains the following parameters:

- `code`: A single-use authorization grant code that’s valid for five minutes. To learn how to validate this code to obtain user tokens, see [`Token validation`](/documentation/SigninwithAppleRESTAPI/Generate-and-validate-tokens).
- `id_token`: A JSON web token (JWT) containing the user’s identity information. For more information, see [`id_token`](/documentation/SigninwithAppleJS/AuthorizationI/id_token).
- `state`: The state contained in the authorization request. Compare against the state value provided in the initial authorization request to help prevent cross-site request forgery attacks.
- `user`: A JSON string containing the data requested in the `scope` property. The returned data is in the following format: `{ "name": { "firstName": string, "lastName": string }, "email": string }`

> Important:
> For privacy, Apple doesn’t receive the user’s full name shared with the system UI. Therefore, the raw data is passed directly to your app from the browser and is not included in the user’s identity token. To prevent cross-site scripting attacks, validate and sanitize the user-submitted first and last name values before storing on your app servers.

Apple only returns the user object the first time the user authorizes the app. Validate and persist this information from your app to your server. Subsequent authorization requests do not contain the `user` object, however, the user’s email is provided in the identity token for all requests. For more information, visit <doc://com.apple.signinwithapple/documentation/signinwithapple/authenticating-users-with-sign-in-with-apple>.

If an error occurs, the HTTP body contains the following parameters:

- `error`: The returned error code
- `state`: The state contained in the authorization request. Compare against the state value provided in the initial authorization request to help prevent cross-site request forgery attacks.

> Note:
> The only error code that might be returned is `user_cancelled_authorize`. This error code is returned if the user clicks the cancel button during the web flow.

### Implement the authorization flow

**Request:**

```
https://appleid.apple.com/auth/authorize?client_id=[CLIENT_ID]&redirect_uri=[REDIRECT_URL]&response_type=code id_token&state=[STATE]&scope=[SCOPES]&response_mode=form_post
```

**Response:**

```json
{
     "authorization": {
       "code": "[CODE]",
       "id_token": "[ID_TOKEN]",
       "state": "[STATE]"
     },
     "user": {
       "email": "[EMAIL]",
       "name": {
         "firstName": "[FIRST_NAME]",
         "lastName": "[LAST_NAME]"
       }
     }
}
```

### Return control to the app

At the end of the authorization flow, Apple performs a `form_post` to the `redirect_uri` value you provided in the request. At this point, the authorization flow is complete, and it’s your server’s responsibility to securely persist the data and return control to the app.

Platforms that support custom URL schemes — iOS 12.0 and earlier and Android — must handle the data resulting from the authorization flow by storing it on their app server in the logic of their `redirect_uri` endpoint. You then redirect the custom URL scheme to give control back to the app.

> Important:
> To help prevent cross-site request forgery attacks, ensure the `state` values contained in the request and response are identical before handling the redirect in your app.

---

Copyright &copy; 2026 Apple Inc. All rights reserved. | [Terms of Use](https://www.apple.com/legal/internet-services/terms/site.html) | [Privacy Policy](https://www.apple.com/privacy/privacy-policy)