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:
-
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.
-
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.
-
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 aktualisierenAdminInitiateAuth
können, wenn die gespeicherten Geräte in Ihrem Benutzerpool nicht aktiv sind. Wenn die gespeicherten Geräte aktiv sind, aktualisieren Sie die Tokens mitAuthFlow
der Option „REFRESH_TOKEN_AUTH
In“InitiateAuth
oder „AdminInitiateAuth
APIAnfragen“.
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
Anfrageparameter im Header
Authorization
-
Wenn dem Client ein geheimer Schlüssel zugewiesen wurde, kann der Client sein
client_id
undclient_secret
im Autorisierungsheader alsclient_secret_basic
HTTP Autorisierung übergeben. Sie können auch dieclient_id
und dasclient_secret
im Anforderungstext alsclient_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-Clientdjc98u3jiedmi283eu928
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
oderrefresh_token
oderclient_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_credentials
ist. redirect_uri
-
(Optional) Muss derselbe sein
redirect_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
istrefresh_token
aberrefresh_token
ist nicht enthalten. invalid_client
-
Client-Authentifizierung ist fehlgeschlagen. Wenn der Client zum Beispiel
client_id
undclient_secret
im Autorisierungs-Header enthält, aber kein Client mit dieserclient_id
und diesemclient_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 im angeforderten Bereich. Zum Beispiel fordert Ihre App den
email
-Bereich an und Ihr App-Client kann das Attributemail
, aber nichtemail_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 alsauthorization_code
oderrefresh_token
oderclient_credentials
.