

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Der Endpunkt des Token-Ausstellers
<a name="token-endpoint"></a>

Der OAuth [2.0-Token-Endpunkt unter `/oauth2/token` gibt JSON-Webtoken](https://www.rfc-editor.org/rfc/rfc6749#section-3.2) (JWTs) an Anwendungen aus, die die Gewährung von Autorisierungscode und Kundenanmeldedaten abschließen möchten. Diese Token sind das Endergebnis der Authentifizierung mit einem Benutzerpool. Sie enthalten Informationen über den Benutzer (ID-Token), die Zugriffsebene des Benutzers (Zugriffstoken) und die Berechtigung des Benutzers, seine angemeldete Sitzung beizubehalten (Aktualisierungstoken). Rely-Party-Bibliotheken von OpenID Connect (OIDC) verarbeiten Anfragen an und Antwortnutzlasten von diesem Endpunkt aus. Tokens bieten einen überprüfbaren Authentifizierungsnachweis, Profilinformationen und einen Mechanismus für den Zugriff auf Backend-Systeme.

Ihr Benutzerpool OAuth 2.0-Autorisierungsserver gibt JSON-Webtoken (JWTs) vom Token-Endpunkt für die folgenden Sitzungstypen aus:

1. Benutzer, die eine Anfrage für die Gewährung eines Autorisierungscodes abgeschlossen haben. Wenn ein Code erfolgreich eingelöst wurde, werden ID-, Zugriffs- und Aktualisierungstoken zurückgegeben.

1. Machine-to-machine (M2M) -Sitzungen, für die eine Erteilung von Kundenanmeldedaten abgeschlossen wurde. Bei erfolgreicher Autorisierung mit dem geheimen Client-Schlüssel wird ein Zugriffstoken zurückgegeben.

1. Benutzer, die sich zuvor angemeldet und Aktualisierungstoken erhalten haben. Bei der Aktualisierungstoken-Authentifizierung werden neue ID- und Zugriffstoken zurückgegeben.
**Anmerkung**  
Benutzer, die sich mit einem Autorisierungscode anmelden, der bei der verwalteten Anmeldung oder über den Verbund gewährt wurde, können ihre Token jederzeit vom Token-Endpunkt aus aktualisieren. Benutzer, die sich mit den API-Vorgängen anmelden `InitiateAuth` und ihre Token mit dem Token-Endpunkt aktualisieren `AdminInitiateAuth` können, [wenn die gespeicherten Geräte](amazon-cognito-user-pools-device-tracking.md) in Ihrem Benutzerpool *nicht* aktiv sind. Wenn die gespeicherten Geräte aktiv sind, aktualisieren Sie die Token mit dem [entsprechenden API- oder SDK-Token-Aktualisierungsvorgang](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-api) für Ihren App-Client.

Der Token-Endpunkt wird öffentlich verfügbar, wenn Sie Ihrem Benutzerpool eine Domain hinzufügen. Er akzeptiert HTTP-POST-Anfragen. Verwenden Sie aus Gründen der Anwendungssicherheit PKCE mit Ihren Autorisierungscode-Anmeldeereignissen. PKCE überprüft, ob der Benutzer, der einen Autorisierungscode übergibt, derselbe Benutzer ist, der sich authentifiziert hat. Weitere Informationen zu PKCE finden Sie unter [IETF](https://datatracker.ietf.org/doc/html/rfc7636) RFC 7636.

Weitere Informationen zu den App-Clients im Benutzerpool und ihren Grant-Typen, Client-Geheimnissen, zulässigen Bereichen und Clients finden Sie unter. IDs [Anwendungsspezifische Einstellungen mit App-Clients](user-pool-settings-client-apps.md) Weitere Informationen zur M2M-Autorisierung, zur Erteilung von Kundenanmeldedaten und zur Autorisierung mit Zugriffstoken finden Sie unter. [Bereiche, M2M und Ressourcenserver](cognito-user-pools-define-resource-servers.md)

Um Informationen über einen Benutzer aus seinem Zugriffstoken abzurufen, geben Sie diese an Ihre Anfrage [UserInfo-Endpunkt](userinfo-endpoint.md) oder an eine [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html)API-Anfrage weiter. Das Zugriffstoken muss die entsprechenden Bereiche für diese Anfragen enthalten,

## Formatieren Sie eine POST-Anforderung für den Token-Endpunkt
<a name="post-token"></a>

Der `/oauth2/token` Endpunkt unterstützt ausschließlich `HTTPS POST`. Dieser Endpunkt ist nicht benutzerinteraktiv. Behandeln Sie Token-Anfragen mit einer [OpenID Connect (OIDC) -Bibliothek in Ihrer Anwendung](https://openid.net/developers/certified-openid-connect-implementations/).

Der Token-Endpunkt unterstützt `client_secret_basic`- und `client_secret_post`-Authentifizierung. [Weitere Informationen zur OIDC-Spezifikation finden Sie unter Client-Authentifizierung.](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) Weitere Informationen zum Token-Endpunkt aus der OpenID-Connect-Spezifikation finden Sie unter [Token-Endpunkt](http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint).

### Anfrageparameter im Header
<a name="post-token-request-parameters"></a>

Sie können die folgenden Parameter im Header Ihrer Anfrage an den Token-Endpunkt übergeben.

**`Authorization`**  
Falls dem Client ein Geheim-Schlüssel zugestellt wurde, kann der Client seine `client_id` und sein `client_secret` im Autorisierungs-Header als `client_secret_basic` HTTP-Autorisierung übergeben. Sie können auch die `client_id` und das `client_secret` im Anforderungstext als `client_secret_post`-Autorisierung aufnehmen.  
Die Autorisierungs-Header-Stringl autet [Basic](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)`. Das folgende Beispiel ist ein Autorisierungsheader für den App-Client `djc98u3jiedmi283eu928` mit dem geheimen Clientschlüssel`abcdef01234567890`, der die Base64-kodierte Version der Zeichenfolge verwendet: `djc98u3jiedmi283eu928:abcdef01234567890`  

```
Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
```

**`Content-Type`**  
Stellen Sie den Wert dieses Parameters auf `'application/x-www-form-urlencoded'` ein.

### Anfrageparameter im Fließtext
<a name="post-token-request-parameters-in-body"></a>

Die folgenden Parameter können Sie im `x-www-form-urlencoded` Format im Anforderungstext für den Token-Endpunkt anfordern.

**`grant_type`**  
*Pflichtfeld*  
Die Art des OIDC-Zuschusses, den Sie beantragen möchten.  
Es muss sich entweder um `authorization_code` oder `refresh_token` oder `client_credentials` handeln. Unter den folgenden Bedingungen können Sie vom Token-Endpunkt aus ein Zugriffstoken für einen benutzerdefinierten Bereich anfordern:  
+ Sie haben den angeforderten Bereich in Ihrer App-Client-Konfiguration aktiviert.
+ Sie haben Ihren App-Client mit einem geheimen Clientschlüssel konfiguriert.
+ Sie aktivieren die Gewährung von Kundenanmeldedaten in Ihrem App-Client.
Der Token-Endpunkt gibt nur dann ein Aktualisierungstoken zurück, wenn dies der `grant_type` Fall ist`authorization_code`.

**`client_id`**  
*Optional. Nicht erforderlich, wenn Sie die App-Client-ID im `Authorization` Header angeben.*  
Die ID eines App-Clients in Ihrem Benutzerpool. Geben Sie denselben App-Client an, der Ihren Benutzer authentifiziert hat.  
Sie müssen diesen Parameter angeben, wenn der Client öffentlich ist und kein Geheimnis hat, oder wenn er `client_secret_post` autorisiert ist. `client_secret`

**`client_secret`**  
*Optional. Nicht erforderlich, wenn Sie das geheime Client-Geheimnis im `Authorization` Header angeben und wenn der App-Client kein Geheimnis hat.*  
Das geheime Geheimnis des App-Clients, falls der App-Client über eines verfügt, für die `client_secret_post` Autorisierung.

**`scope`**  
*Optional*.  
Kann eine Kombination aller Bereiche sein, die Ihrem App-Client zugeordnet sind. Amazon Cognito ignoriert Bereiche in der Anfrage, die für den angeforderten App-Client nicht zulässig sind. Wenn Sie diesen Anforderungsparameter nicht angeben, gibt der Autorisierungsserver einen `scope` Zugriffstoken-Anspruch mit allen Autorisierungsbereichen zurück, die Sie in Ihrer App-Client-Konfiguration aktiviert haben. Sie können alle Bereiche anfordern, die für den angeforderten App-Client zulässig sind: Standardbereiche, benutzerdefinierte Bereiche von Ressourcenservern und der `aws.cognito.signin.user.admin` Self-Service-Bereich für Benutzer.

**`redirect_uri`**  
*Optional. Für die Gewährung von Kundenanmeldedaten nicht erforderlich.*  
Es muss sich um dieselbe `redirect_uri` handeln, die verwendet wurde, um `authorization_code` in `/oauth2/authorize` zu bekommen.  
Falls `grant_type` ja, müssen Sie diesen Parameter angeben. `authorization_code`

**`refresh_token`**  
*Optional. Wird nur verwendet, wenn der Benutzer bereits über ein Aktualisierungstoken verfügt und neue ID- und Zugriffstoken erhalten möchte.*  
Um neue Zugriffs- und ID-Tokens für die Sitzung eines Benutzers `refresh_token` zu generieren, setzen Sie den Wert auf ein gültiges Aktualisierungstoken, das der angeforderte App-Client ausgegeben hat.  
Gibt ein neues Aktualisierungstoken mit neuer ID und Zugriffstoken zurück, wenn die [Aktualisierungstoken-Rotation](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation) aktiv ist. Andernfalls werden nur ID- und Zugriffstoken zurückgegeben. Wenn das ursprüngliche Zugriffstoken [an eine API-Ressource gebunden](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding) war, behält das neue Zugriffstoken die angeforderte API-URL im `aud` Anspruch bei.

**`code`**  
*Optional. Nur bei Erteilung von Autorisierungscodes erforderlich.*  
Der Autorisierungscode aus einer Autorisierungscode-Erteilung. Sie müssen diesen Parameter angeben, wenn Ihre Autorisierungsanfrage ein `grant_type` of enthielt`authorization_code`.

**`aws_client_metadata`**  
*Optional*.  
Informationen, die Sie an die [Lambda-Auslöser für die Vorab-Generierung von Token](user-pool-lambda-pre-token-generation.md) internen [machine-to-machine (M2M)](cognito-user-pools-define-resource-servers.md) -Autorisierungsabläufe weitergeben möchten. Ihre Anwendung kann Kontextinformationen über die Sitzung sammeln und sie in diesem Parameter übergeben. Wenn Sie das URL-kodierte JSON-Format übergeben`aws_client_metadata`, nimmt Amazon Cognito es in das Eingabeereignis für Ihre Trigger-Lambda-Funktion auf. Ihre Pre-Token-Trigger-Event-Version oder globale Lambda-Trigger-Version muss für Version drei oder höher konfiguriert sein. Amazon Cognito akzeptiert zwar Anfragen an diesen Endpunkt in M2M-Datenströmen für Autorisierungscode und Kundenanmeldedaten, Ihr Benutzerpool wird jedoch nur von Anfragen mit Kundenanmeldedaten `aws_client_metadata` an den Trigger vor der Token-Generierung weitergeleitet.

**`code_verifier`**  
Optional. Nur erforderlich, wenn Sie in Ihrer ersten Autorisierungsanfrage `code_challenge` Parameter angegeben `code_challenge_method` haben.  
Der generierte Codeverifizierer, anhand dessen Ihre Anwendung in einer Anfrage zur `code_challenge` Erteilung eines Autorisierungscodes bei [PKCE](using-pkce-in-authorization-code.md) den Wert berechnet hat.

## Austausch eines Autorisierungscodes für Token
<a name="post-token-positive-exchanging-authorization-code-for-tokens"></a>

Mit der folgenden Anfrage werden nach der Authentifizierung mit einem Autorisierungscode erfolgreich ID-, Zugriffs- und Aktualisierungstoken generiert. Die Anfrage übergibt das Client-Geheimnis im `client_secret_basic` Format im Header. `Authorization`

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token&
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=authorization_code&
client_id=1example23456789&
code=AUTHORIZATION_CODE&
redirect_uri=com.myclientapp://myclient/redirect
```

Die Antwort gibt dem Benutzer neue ID-, Zugriffs- und Aktualisierungstoken mit zusätzlichen Metadaten aus.

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj3example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## Kundenanmeldedaten mit Basisautorisierung
<a name="exchanging-client-credentials-for-an-access-token-in-request-body"></a>

Die folgende Anfrage einer M2M-Anwendung fordert die Gewährung von Kundenanmeldedaten an. Da für Client-Anmeldeinformationen ein Client-Geheimnis erforderlich ist, wird die Anfrage mit einem `Authorization` Header autorisiert, der aus der App-Client-ID und dem geheimen Schlüssel abgeleitet wird. Die Anfrage führt zu einem Zugriffstoken mit den beiden angeforderten Bereichen. Die Anfrage enthält auch Client-Metadaten, die IP-Adressinformationen und ein Token enthalten, das an den Benutzer ausgegeben wird, für den die Gewährung erfolgt. Amazon Cognito leitet die Client-Metadaten an den Lambda-Trigger vor der Token-Generierung weiter.

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=client_credentials&
client_id=1example23456789&
scope=resourceServerIdentifier1%2Fscope1%20resourceServerIdentifier2%2Fscope2&
&aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D
```

Amazon Cognito leitet das folgende Eingabeereignis an den Lambda-Trigger vor der Token-Generierung weiter.

```
{
    version: '3',
    triggerSource: 'TokenGeneration_ClientCredentials',
    region: 'us-east-1',
    userPoolId: 'us-east-1_EXAMPLE',
    userName: 'ClientCredentials',
    callerContext: {
        awsSdkVersion: 'aws-sdk-unknown-unknown',
        clientId: '1example23456789'
    },
    request: {
        userAttributes: {},
        groupConfiguration: null,
        scopes: [
           'resourceServerIdentifier1/scope1',
           'resourceServerIdentifier2/scope2'
        ],
        clientMetadata: {
            'onBehalfOfToken': 'eyJra789ghiEXAMPLE',
            'ClientIpAddress': '192.0.2.252'
        }
    },
    response: { claimsAndScopeOverrideDetails: null }
}
```

Die Antwort gibt ein Zugriffstoken zurück. Die Erteilung von Kundenanmeldedaten dient der machine-to-machine (M2M-) Autorisierung und gibt nur Zugriffstoken zurück.

```
HTTP/1.1 200 OK
Content-Type: application/json
{
    "access_token": "eyJra1example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## Kundenanmeldedaten mit POST-Body-Autorisierung
<a name="post-token-positive-exchanging-client-credentials-for-an-access-token-in-request-body"></a>

Die folgende Anfrage zur Gewährung von Kundenanmeldedaten enthält den `client_secret` Parameter im Hauptteil der Anfrage und keinen Header. `Authorization` Diese Anfrage verwendet die `client_secret_post` Autorisierungssyntax. Die Anfrage führt zu einem Zugriffstoken mit dem angeforderten Bereich. Die Anfrage enthält auch Client-Metadaten, die IP-Adressinformationen und ein Token enthalten, das an den Benutzer ausgegeben wird, für den diese Genehmigung erteilt wurde. Amazon Cognito leitet die Client-Metadaten an den Lambda-Trigger vor der Token-Generierung weiter.

```
POST /oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
X-Amz-Target: AWSCognitoIdentityProviderService.Client credentials request
User-Agent: USER_AGENT
Accept: /
Accept-Encoding: gzip, deflate, br
Content-Length: 177
Referer: http://auth.example.com/oauth2/token
Host: auth.example.com
Connection: keep-alive

grant_type=client_credentials&
client_id=1example23456789&
scope=my_resource_server_identifier%2Fmy_custom_scope&
client_secret=9example87654321&
aws_client_metadata=%7B%22onBehalfOfToken%22%3A%22eyJra789ghiEXAMPLE%22,%20%22ClientIpAddress%22%3A%22192.0.2.252%22%7D
```

Amazon Cognito leitet das folgende Eingabeereignis an den Lambda-Trigger vor der Token-Generierung weiter.

```
{
    version: '3',
    triggerSource: 'TokenGeneration_ClientCredentials',
    region: 'us-east-1',
    userPoolId: 'us-east-1_EXAMPLE',
    userName: 'ClientCredentials',
    callerContext: {
        awsSdkVersion: 'aws-sdk-unknown-unknown',
        clientId: '1example23456789'
    },
    request: {
        userAttributes: {},
        groupConfiguration: null,
        scopes: [
           'resourceServerIdentifier1/my_custom_scope'
        ],
        clientMetadata: {
            'onBehalfOfToken': 'eyJra789ghiEXAMPLE',
            'ClientIpAddress': '192.0.2.252'
        }
    },
    response: { claimsAndScopeOverrideDetails: null }
}
```

Die Antwort gibt ein Zugriffstoken zurück. Die Erteilung von Kundenanmeldedaten dient der machine-to-machine (M2M-) Autorisierung und gibt nur Zugriffstoken zurück.

```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Date: Tue, 05 Dec 2023 16:11:11 GMT
x-amz-cognito-request-id: 829f4fe2-a1ee-476e-b834-5cd85c03373b

{
    "access_token": "eyJra12345EXAMPLE",
    "expires_in": 3600,
    "token_type": "Bearer"
}
```

## Erteilung des Autorisierungscodes mit PKCE
<a name="post-token-positive-exchanging-authorization-code-grant-with-pkce-for-tokens"></a>

Die folgende Beispielanforderung vervollständigt eine Autorisierungsanfrage, die `code_challenge` Parameter `code_challenge_method` und Parameter in einer Autorisierungscode-Erteilungsanfrage mit [PKCE](using-pkce-in-authorization-code.md) beinhaltet.

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=authorization_code&
client_id=1example23456789&
code=AUTHORIZATION_CODE&
code_verifier=CODE_VERIFIER&
redirect_uri=com.myclientapp://myclient/redirect
```

In der Antwort werden ID-, Zugriffs- und Aktualisierungstoken aus der erfolgreichen PKCE-Überprüfung durch die Anwendung zurückgegeben.

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj3example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## Token-Aktualisierung ohne Token-Rotation
<a name="post-token-positive-exchanging-a-refresh-token-for-tokens"></a>

Die folgende Beispielanforderung stellt ein Aktualisierungstoken für einen App-Client bereit, bei dem die [Rotation des Aktualisierungstokens](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation) inaktiv ist. Da der App-Client über ein geheimes Client-Geheimnis verfügt, stellt die Anfrage einen `Authorization` Header bereit.

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=refresh_token&
client_id=1example23456789&
refresh_token=eyJj3example
```

Die Antwort gibt neue IDs und Zugriffstoken zurück.

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## Token-Aktualisierung mit Rotation des Aktualisierungstokens
<a name="post-token-positive-refresh-token-rotation"></a>

Die folgende Beispielanforderung stellt ein Aktualisierungstoken für einen App-Client bereit, für den die [Rotation des Aktualisierungstokens](amazon-cognito-user-pools-using-the-refresh-token.md#using-the-refresh-token-rotation) aktiv ist. Da der App-Client über ein geheimes Client-Geheimnis verfügt, stellt die Anfrage einen `Authorization` Header bereit.

```
POST https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/token >
Content-Type='application/x-www-form-urlencoded'&
Authorization=Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw

grant_type=refresh_token&
client_id=1example23456789&
refresh_token=eyJj3example
```

Die Antwort gibt neue ID-, Zugriffs- und Aktualisierungstoken zurück.

```
HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJra1example",
    "id_token": "eyJra2example",
    "refresh_token": "eyJj4example",
    "token_type": "Bearer",
    "expires_in": 3600
}
```

## Beispiele für negative Antworten
<a name="post-token-negative"></a>

Fehlerhafte Anfragen erzeugen Fehler vom Token-Endpunkt aus. Im Folgenden finden Sie eine allgemeine Übersicht über den Antworttext, wenn Token-Anfragen einen Fehler generieren.

```
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8

{
"error":"invalid_request|invalid_client|invalid_grant|unauthorized_client|unsupported_grant_type"
}
```

**`invalid_request`**  
Der Anforderung fehlt ein erforderlicher Parameter, sie umfasst einen nicht unterstützten Parameter-Wert (außer `unsupported_grant_type`) oder sie ist aus anderen Gründen ungültig. Beispielsweise, `grant_type` ist `refresh_token` aber `refresh_token` ist nicht enthalten. 

**`invalid_client`**  
Client-Authentifizierung ist fehlgeschlagen. Wenn der Client zum Beispiel `client_id` und `client_secret` im Autorisierungs-Header enthält, aber kein Client mit dieser `client_id` und diesem `client_secret`existiert. 

**`invalid_grant`**  
Das Refresh-Token wurde widerrufen.   
Der Autorisierungs-Code wurde bereits verwendet oder ist nicht vorhanden.   
Der App-Client hat keinen Lesezugriff auf alle [Attribute](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html) im angeforderten Bereich. Zum Beispiel fordert Ihre App den `email`-Bereich an und Ihr App-Client kann das Attribut `email`, aber nicht `email_verified` lesen.

**`unauthorized_client`**  
Dem Client ist es nicht gestattet, einen Code zu gewähren oder Token zu aktualisieren. 

**`unsupported_grant_type`**  
Wird zurückgegeben, wenn `grant_type` ein anderer Wert ist als `authorization_code` oder `refresh_token` oder `client_credentials`. 