Token-Endpunkt - Amazon Cognito
POST/oauth2/token

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.

Token-Endpunkt

Der OAuth 2.0-Token-Endpunkt /oauth2/token gibt JSON Web-Token aus ()JWTs.

Ihr Benutzerpool OAuth 2.0-Autorisierungsserver gibt JSON Web-Token (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.

  2. M achine-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.

  3. 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 erteilten Autorisierungscode auf der gehosteten Benutzeroberfläche oder über einen Verbund anmelden, können ihre Token jederzeit vom Token-Endpunkt aus aktualisieren. Benutzer, die sich bei den API Vorgängen anmelden InitiateAuth und ihre Token mit dem Token-Endpunkt aktualisieren AdminInitiateAuth können, wenn die gespeicherten Geräte in Ihrem Benutzerpool nicht aktiv sind. Wenn die gespeicherten Geräte aktiv sind, aktualisieren Sie die Tokens mit AuthFlow der Option „REFRESH_TOKEN_AUTHIn“ InitiateAuth oder „AdminInitiateAuthAPIAnfragen“.

Der Token-Endpunkt wird öffentlich verfügbar, wenn Sie Ihrem Benutzerpool eine Domain hinzufügen. Es akzeptiert HTTP POST Anfragen. Verwenden Sie aus Gründen der Anwendungssicherheit Anmeldeereignisse PKCE zusammen mit Ihrem Autorisierungscode. PKCEüberprüft, ob der Benutzer, der einen Autorisierungscode übergibt, derselbe Benutzer ist, der sich authentifiziert hat. Weitere Informationen dazu finden Sie unter PKCE IETF RFC 7636.

Weitere Informationen zu den App-Clients im Benutzerpool und ihren Grant-Typen, Client-Geheimnissen, autorisierten Bereichen und Clients IDs finden Sie unter. App-Clients für Benutzerpools Weitere Informationen zur M2M-Autorisierung, zur Erteilung von Kundenanmeldedaten und zur Autorisierung mit Zugriffstoken finden Sie unter. Geltungsbereiche, M2M und API Autorisierung mit Ressourcenservern

Um Informationen über einen Benutzer aus seinem Zugriffstoken abzurufen, geben Sie diese an Ihren UserInfo-Endpunkt oder an eine GetUserAPIAnfrage weiter.

POST/oauth2/token

Der /oauth2/token Endpunkt unterstützt ausschließlich HTTPS POST. Ihre Anwendung sendet Anfragen direkt an diesen Endpunkt und nicht über den Browser des Benutzers.

Der Token-Endpunkt unterstützt client_secret_basic- und client_secret_post-Authentifizierung. Weitere Informationen zur OpenID Connect-Spezifikation finden Sie unter Client Authentication. Weitere Informationen zum Token-Endpunkt aus der OpenID-Connect-Spezifikation finden Sie unter Token-Endpunkt.

Anfrageparameter im Header

Authorization

Wenn dem Client ein geheimer Schlüssel zugewiesen wurde, kann der Client sein client_id und client_secret im Autorisierungsheader 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 Base64Encode(client_id:client_secret). Das folgende Beispiel ist ein Autorisierungsheader für einen App-Client djc98u3jiedmi283eu928 mit einem geheimen Clientschlüsselabcdef01234567890, wobei die Base64-kodierte Version der Zeichenfolge verwendet wird: djc98u3jiedmi283eu928:abcdef01234567890

Authorization: Basic ZGpjOTh1M2ppZWRtaTI4M2V1OTI4OmFiY2RlZjAxMjM0NTY3ODkw
Content-Type

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

Anfrageparameter im Fließtext

grant_type

(Erforderlich) 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.

client_id

(Optional) 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) Der geheime Client-Schlüssel für den App-Client, der Ihren Benutzer authentifiziert hat. Erforderlich, wenn Ihr App-Client über einen Client-Schlüssel verfügt und Sie keinen Authorization-Header gesendet haben.

scope

(Optional) Kann eine Kombination aus beliebigen benutzerdefinierten Bereichen sein, die einem App-Client zugeordnet sind. Jeder Bereich, den Sie anfordern, muss für den App-Client aktiviert sein. Wenn nicht, ignoriert Amazon Cognito es. Wenn der Client keine Bereiche anfordert, weist der Authentifizierungsserver alle benutzerdefinierten Bereiche zu, die Sie in Ihrer App-Client-Konfiguration autorisiert haben.

Wird nur verwendet, wenn grant_type client_credentialsist.

redirect_uri

(Optional) Muss derselbe seinredirect_uri, der für den Zugang verwendet wurde. authorization_code /oauth2/authorize

Wenn grant_type ja, müssen Sie diesen Parameter angebenauthorization_code.

refresh_token

(Optional) Um neue Zugriffs- und ID-Token für die Sitzung eines Benutzers zu generieren, setzen Sie den Wert eines refresh_token Parameters in Ihrer /oauth2/token Anfrage auf ein zuvor ausgegebenes Aktualisierungstoken von demselben App-Client.

code

(Optional) Der Autorisierungscode aus einer Autorisierungscode-Erteilung. Sie müssen diesen Parameter angeben, wenn Ihre Autorisierungsanfrage ein grant_type of enthieltauthorization_code.

code_verifier

(Optional) Der willkürliche Wert, mit dem Sie den code_challenge in einer Autorisierungscode-Erteilungsanforderung berechnet habenPKCE.

Beispielanfragen mit positiven Antworten

Austausch eines Autorisierungscodes für Token

Beispiel — POST Anfrage

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

Beispiel — Antwort

HTTP/1.1 200 OK
                        
                           Content-Type: application/json
                           
                           { 
                            "access_token":"eyJra1example", 
                            "id_token":"eyJra2example",
                            "refresh_token":"eyJj3example",
                            "token_type":"Bearer", 
                            "expires_in":3600
                           }
Anmerkung

Der Token-Endpunkt wird refresh_token nur zurückgegeben, wenn der grant_type authorization_code ist.

Austauschen von Client-Anmeldedaten für ein Zugriffs-Token: Client-Schlüssel im Authentifizierungs-Header

Beispiel — POST Anfrage

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/scope1 resourceServerIdentifier2/scope2

Beispiel — Antwort

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

Austauschen von Client-Anmeldedaten für ein Zugriffs-Token: Client-Schlüssel im Anforderungstext

Beispiel — POST Anfrage

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

Beispiel — Antwort

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"
}

Austauschen eines gewährten Autorisierungscodes PKCE gegen Tokens

Beispiel — POST Anfrage

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

Beispiel — Antwort

HTTP/1.1 200 OK
                            Content-Type: application/json
                            
                            {
                            "access_token":"eyJra1example", 
                            "id_token":"eyJra2example",
                            "refresh_token":"eyJj3example",
                            "token_type":"Bearer", 
                            "expires_in":3600
                            }
Anmerkung

Der Token-Endpunkt wird refresh_token nur zurückgegeben, wenn der grant_type authorization_code ist.

Austausch eines Refresh-Tokens für Token

Beispiel — POST Anfrage

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

Beispiel — Antwort

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

Der Token-Endpunkt wird refresh_token nur zurückgegeben, wenn der grant_type authorization_code ist.

Beispiele für negative Antworten

Beispiel — Fehlerantwort

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

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