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.
# Identitätsanbieter und Endpunkte der vertrauenden Partei
*Verbundendpunkte* sind Benutzerpool-Endpunkte, die einem der von Benutzerpools verwendeten Authentifizierungsstandards dienen. Dazu gehören SAML-ACS URLs, OIDC-Erkennungsendpunkte und Dienstendpunkte für Benutzerpools, die sowohl als Identitätsanbieter als auch als vertrauende Partei fungieren. Verbundendpunkte initiieren Authentifizierungsabläufe, erhalten Authentifizierungsnachweise von Clients und stellen Token an diese aus IdPs. Sie interagieren mit IdPs Anwendungen und Administratoren, aber nicht mit Benutzern.
Die ganzseitigen Themen nach dieser Seite enthalten Informationen zu den OAuth 2.0- und OIDC-Provider-Endpunkten, die verfügbar werden, wenn Sie Ihrem Benutzerpool eine Domain hinzufügen. Die folgende Tabelle enthält eine Liste aller Verbundendpunkte.
Beispiele für [Benutzerpool-Domänen sind:](cognito-user-pools-assign-domain.md)
1. Präfixdomäne: `mydomain.auth.us-east-1.amazoncognito.com`
1. Benutzerdefinierte Domain: `auth.example.com`
**Benutzerpool-Verbund-Endpunkte**
| Endpunkt-URL | Description | Zugriff darauf |
| --- | --- | --- |
| https://Your user pool domain/oauth2/authorize | Leitet einen Benutzer entweder zur verwalteten Anmeldung oder zur Anmeldung mit seinem IdP weiter. | Wird im Kundenbrowser aufgerufen, um mit der Benutzerauthentifizierung zu beginnen. Siehe [Autorisieren des Endpunkts](authorization-endpoint.md). |
| https://Your user pool domain/oauth2/token | Gibt Token auf der Grundlage eines Autorisierungscodes oder einer Anforderung von Kundenanmeldeinformationen zurück. | Von der App zum Abrufen von Token angefordert. Siehe [Token-Endpunkt](token-endpoint.md). |
| https://Your user pool domainOAuth2/UserInfo | Gibt Benutzerattribute basierend auf OAuth 2.0-Bereichen und Benutzeridentität in einem Zugriffstoken zurück. | Von der App zum Abrufen des Benutzerprofils angefordert. Siehe [UserInfo-Endpunkt](userinfo-endpoint.md). |
| https://Your user pool domain/oauth2/revoke | Widerruft ein Aktualisierungs-Token und die zugehörigen Zugriffs-Token. | Von der App aufgefordert, ein Token zu widerrufen. Siehe [Widerrufen des Endpunkts](revocation-endpoint.md). |
| https://cognito-idp. Region.amazonaws.com/ /.well-known/openid-configuration your user pool ID | Ein Verzeichnis der OIDC-Architektur Ihres Benutzerpools. [1](#cognito-federation-oidc-discovery-note) | Von der App angefordert, um Metadaten des Benutzerpool-Emittenten zu finden. |
| https://cognito-idp. Region.amazonaws.com/ /.well-known/jwks.json your user pool ID | Öffentliche Schlüssel, mit denen Sie Amazon Cognito Cognito-Token validieren können. [2](#cognito-federation-oidc-jwks-note) | Von der App zur Überprüfung angefordert JWTs. |
| https://Your user pool domain/oauth2/idpresponse | Social-Identitätsanbieter müssen Ihre Benutzer mit einem Autorisierungscode an diesen Endpunkt umleiten. Amazon Cognito löst den Code gegen ein Token ein, wenn es Ihren Verbundbenutzer authentifiziert. | Weitergeleitet von der OIDC-IdP-Anmeldung als IdP-Client-Callback-URL. |
| https://Your user pool domain/saml2/idpresponse | Die Assertion Consumer Response (ACS) -URL für die Integration mit SAML 2.0-Identitätsanbietern. | Umgeleitet von SAML 2.0-IdP als ACS-URL oder Ausgangspunkt für die vom IdP initiierte Anmeldung. [3](#cognito-federation-idp-init-note) |
| httpsYour user pool domain:///saml2/logout | Die [Single Logout](cognito-user-pools-saml-idp-sign-out.md#cognito-user-pools-saml-idp-sign-out.title) (SLO) -URL für die Integration mit SAML 2.0-Identitätsanbietern. | Umgeleitet von SAML 2.0 IdP als Single Logout (SLO) -URL. Akzeptiert nur POST-Bindung. |
1 Das `openid-configuration` Dokument kann jederzeit mit zusätzlichen Informationen aktualisiert werden, damit der Endpunkt dem OIDC und OAuth2 den Spezifikationen entspricht.
2 Die `jwks.json` JSON-Datei kann jederzeit mit neuen öffentlichen Token-Signaturschlüsseln aktualisiert werden.
3 Weitere Informationen zur IDP-initiierten SAML-Anmeldung finden Sie unter. [Implementieren Sie die IDP-initiierte SAML-Anmeldung](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-SAML-session-initiation-idp-initiation)
[Weitere Informationen zu OpenID Connect und den OAuth Standards finden Sie unter [OpenID Connect 1.0 und OAuth 2.0](http://openid.net/specs/openid-connect-core-1_0.html).](https://tools.ietf.org/html/rfc6749)
**Topics**
+ [
# Der Umleitungs- und Autorisierungsendpunkt
](authorization-endpoint.md)
+ [
# Der Endpunkt des Token-Ausstellers
](token-endpoint.md)
+ [
# Der Endpunkt der Benutzerattribute
](userinfo-endpoint.md)
+ [
# Der Endpunkt für den Token-Widerruf
](revocation-endpoint.md)
+ [
# Der IdP-SAML-Assertion-Endpunkt
](saml2-idpresponse-endpoint.md)
# Der Umleitungs- und Autorisierungsendpunkt
Der `/oauth2/authorize`-Endpunkt ist ein Umleitungsendpunkt, der zwei Umleitungsziele unterstützt. Wenn Sie einen `identity_provider`- oder `idp_identifier`-Parameter in der URL angeben, werden Ihre Benutzer im Hintergrund auf die Anmeldeseite für diesen Identitätsanbieter (IDP) umgeleitet. Andernfalls erfolgt die Umleitung an [Login-Endpunkt](login-endpoint.md) mit denselben URL-Parametern, die Sie in Ihre Anfrage aufgenommen haben.
Der Autorisierungsendpunkt leitet entweder zur verwalteten Anmeldung oder zu einer IdP-Anmeldeseite weiter. Das Ziel einer Benutzersitzung an diesem Endpunkt ist eine Webseite, mit der Ihr Benutzer direkt in seinem Browser interagieren muss.
Wenn Sie den Autorisierungsendpunkt verwenden möchten, rufen Sie den Browser Ihres Benutzers unter `/oauth2/authorize` mit Parametern auf, die Ihrem Benutzerpool Informationen zu den folgenden Benutzerpool-Details liefern.
+ Der App-Client, bei dem Sie sich anmelden möchten.
+ Die Rückruf-URL, zu der Sie gelangen möchten.
+ Die OAuth 2.0-Bereiche, die Sie im Zugriffstoken Ihres Benutzers anfordern möchten.
+ Optionaler Drittanbieter-IDP, den Sie für die Anmeldung verwenden möchten.
Sie können auch `state`- und `nonce`-Parameter angeben, die Amazon Cognito verwendet, um eingehende Ansprüche zu validieren.
## GET `/oauth2/authorize`
Der `/oauth2/authorize` Endpunkt unterstützt ausschließlich `HTTPS GET`. Ihre App initiiert diese Anfrage normalerweise im Browser Ihres Benutzers. Sie können nur über HTTPS Anfragen an den `/oauth2/authorize`-Endpunkt stellen.
Weitere Informationen über die Definition des Autorisierungsendpunkts im OpenID Connect (OIDC)-Standard finden Sie unter [Authorisierungsendpunkt](http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthorizationEndpoint).
### Anforderungsparameter
**`response_type`**
Erforderlich
Die Art der Antwort. Es muss sich entweder um `code` oder `token` handeln.
Eine erfolgreiche Anfrage mit einem `response_type` von `code` gibt eine Autorisierungscode-Erteilung zurück. Eine Autorisierungscode-Erteilung ist ein `code`-Parameter, den Amazon Cognito an Ihre Umleitungs-URL anhängt. Ihre App kann den Code durch Zugriffs-, ID- und Aktualisierungstoken austauschen. Verwenden Sie als bewährte Sicherheitsmethode und zum Abrufen von Aktualisierungstoken für Ihre Benutzer eine Autorisierungscode-Erteilung in Ihrer App.
Eine erfolgreiche Anfrage mit dem `response_type` `token` gibt eine implizite Erteilung zurück. Eine implizite Erteilung besteht aus einer ID und einem Zugriffstoken, die Amazon Cognito an Ihre Umleitungs-URL anhängt. Eine implizite Erteilung ist weniger sicher, da sie Token und potenzielle identifizierende Informationen für Benutzer verfügbar macht. Sie können die Unterstützung für implizite Erteilungen in der Konfiguration Ihres App-Clients deaktivieren.
**`client_id`**
Erforderlich
Die App-Client-ID).
Der Wert `client_id` muss die ID eines App-Clients in dem Benutzerpool sein, in dem Sie die Anfrage stellen. Ihr App-Client muss die Anmeldung durch lokale Benutzer von Amazon Cognito oder mindestens eines externen IdPs unterstützen.
**`redirect_uri`**
Erforderlich
Die URL, an die der Authentifizierungsserver den Browser nach der Autorisierung des Benutzers durch Amazon Cognito weiterleitet.
Ein Umleitungs-URI (Uniform Resource Identifier) muss die folgenden Attribute aufweisen:
+ Es muss ein absoluter URI sein.
+ Sie müssen die URI im Vorfeld mit einem Client registriert haben.
+ Sie darf keine Fragmentkomponente enthalten.
Siehe [OAuth 2.0 — Endpunkt der Umleitung](https://tools.ietf.org/html/rfc6749#section-3.1.2).
Amazon Cognito erfordert, dass Ihr Umleitungs-URI HTTPS verwendet, mit Ausnahme von `http://localhost`, was Sie als Rückruf-URL für Testzwecke festlegen können.
Amazon Cognito unterstützt auch App-Callback URLs wie. `myapp://example`
**`state`**
Optional, empfohlen.
Wenn Ihre App einer Anfrage einen Parameter *state* hinzufügt, gibt Amazon Cognito seinen Wert an Ihre App zurück, wenn der Endpunkt `/oauth2/authorize` Ihren Benutzer umleitet.
Fügen Sie diesen Wert Ihren Anfragen hinzu, um sich vor [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery)-Angriffen zu schützen.
Sie können den Wert eines Parameters `state` nicht auf eine URL-codierte JSON-Zeichenfolge festlegen. Um eine Zeichenfolge, die diesem Format entspricht, in einem `state` Parameter zu übergeben, kodieren Sie die Zeichenfolge in Base64 und dekodieren Sie sie dann in Ihrer App.
**`identity_provider`**
Optional.
Fügen Sie diesen Parameter hinzu, um die verwaltete Anmeldung zu umgehen und Ihren Benutzer auf die Anmeldeseite eines Anbieters umzuleiten. Der Wert des *identity\$1provider*-Parameters ist der Name des Identitätsanbieters (IDP), wie er in Ihrem Benutzerpool angezeigt wird.
+ Für soziale Anbieter können Sie die *identity\$1provider-Werte*`Facebook`,, und `Google` verwenden. `LoginWithAmazon` `SignInWithApple`
+ Verwenden Sie für Amazon Cognito Cognito-Benutzerpools den Wert`COGNITO`.
+ Verwenden Sie für SAML 2.0- und OpenID Connect (OIDC-) Identitätsanbieter (IdPs) den Namen, den Sie dem IdP in Ihrem Benutzerpool zugewiesen haben.
**`idp_identifier`**
Optional.
Fügen Sie diesen Parameter für die Umleitung an einen Anbieter mit einem alternativen Namen für *identity\$1provider* hinzu. Sie können Identifikatoren für Ihre SAML 2.0 und OIDC IdPs im Menü **Soziale Netzwerke und externe Anbieter der Amazon Cognito** Cognito-Konsole eingeben.
**`scope`**
Optional.
Dabei kann es sich um eine Kombination aus für das System reservierten Bereichen oder benutzerdefinierten Bereichen, die einem Client zugeordnet sind, handeln. Bereiche müssen durch Leerzeichen getrennt werden. Für das System reservierte Bereiche sind `openid``email`, `phone`, `profile` und `aws.cognito.signin.user.admin`. Jeder Bereich muss dem Client zugeordnet werden, sonst wird der Client zur Laufzeit ignoriert.
Falls der Client keine Bereiche anfordert, verwendet der Authentifizierungsserver alle Bereiche im Zusammenhang mit dem Client.
Ein ID-Token wird nur zurückgegeben, wenn der `openid`-Bereich angefordert wird. Das Zugriffs-Token kann nur gegen Amazon-Cognito-Benutzerpools verwendet werden, wenn der Bereich `aws.cognito.signin.user.admin` angefordert wird. Die Bereiche `phone`, `email` und `profile` können nur angefordert werden, wenn der Bereich `openid` ebenfalls angefordert wird. Diese Bereiche bestimmen die Anträge, die im ID-Token eingesetzt werden.
**`code_challenge_method`**
Optional.
Das Hashing-Protokoll, das Sie zur Generierung der Herausforderung verwendet haben. Die [PKCE RFC](https://tools.ietf.org/html/rfc7636) definiert zwei Methoden, die S256-Methode und eine einfache. Der Amazon-Cognito-Authentifikationsserver unterstützt jedoch nur die S256-Methode.
**`code_challenge`**
Optional.
Die PKCE-Abfrage (Proof of Key Code Exchange), die Sie anhand der generiert haben. `code_verifier` Weitere Informationen finden Sie unter [Verwendung von PKCE in Autorisierungscode-Zuschüssen](using-pkce-in-authorization-code.md).
Nur erforderlich, wenn Sie einen `code_challenge_method`-Parameter angeben.
**`nonce`**
Optional.
Ein Zufallswert, den Sie der Anforderung hinzufügen können. Der von Ihnen bereitgestellte Nonce-Wert ist im ID-Token enthalten, das Amazon Cognito ausgibt. Zum Schutz vor Replay-Angriffen kann Ihre App den `nonce`-Anspruch im ID-Token untersuchen und mit dem vergleichen, den Sie generiert haben. Weitere Informationen zum `nonce`-Anspruch finden Sie unter [ID-Token-Validierung](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) im *OpenID Connect-Standard*.
**`lang`**
Optional.
Die Sprache, in der Sie benutzerinteraktive Seiten anzeigen möchten. Verwaltete Anmeldeseiten können lokalisiert werden, gehostete UI-Seiten (klassische Seiten) jedoch nicht. Weitere Informationen finden Sie unter [Lokalisierung bei verwalteter Anmeldung](cognito-user-pools-managed-login.md#managed-login-localization).
**`login_hint`**
Optional.
Eine Aufforderung zur Eingabe eines Benutzernamens, die Sie an den Autorisierungsserver weiterleiten möchten. Sie können einen Benutzernamen, eine E-Mail-Adresse oder eine Telefonnummer von Ihrem Benutzer erfassen und dem Zielanbieter erlauben, den Anmeldenamen des Benutzers vorab auszufüllen. Wenn Sie einen `login_hint` Parameter und keine `idp_identifier` oder `identity_provider` Parameter an den `oauth2/authorize` Endpunkt senden, füllt Managed Login das Feld für den Benutzernamen mit Ihrem Hinweiswert aus. Sie können diesen Parameter auch an den übergeben [Login-Endpunkt](login-endpoint.md) und den Wert für den Benutzernamen automatisch ausfüllen.
Wenn Ihre Autorisierungsanfrage eine Weiterleitung zu OIDC aufruft IdPs, fügt Amazon Cognito der Anfrage an diesen Drittanbieter-Autorisierer einen `login_hint` Parameter hinzu. Sie können Anmeldehinweise nicht an SAML, Apple, Login With Amazon, Google oder Facebook (Meta) IdPs weiterleiten.
**`prompt`**
Optional.
Ein OIDC-Parameter, der das Authentifizierungsverhalten für bestehende Sitzungen steuert. Nur in der Branding-Version für verwaltete Anmeldung verfügbar, nicht in der klassischen gehosteten Benutzeroberfläche. Weitere Informationen aus der OIDC-Spezifikation finden Sie unter [Authentifizierungsanfrage](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). Die Werte `none` und `login` wirken sich auf das Authentifizierungsverhalten des Benutzerpools aus.
Amazon Cognito leitet alle Werte von weiter`none`, `prompt` außer an Ihre, IdPs wenn Benutzer die Authentifizierung bei Drittanbietern auswählen. Dies ist der Fall, wenn die URL, auf die Benutzer zugreifen, einen `identity_provider` `idp_identifier` OR-Parameter enthält oder wenn der Autorisierungsserver sie an den weiterleitet [Login-Endpunkt](login-endpoint.md) und sie einen IdP aus den verfügbaren Schaltflächen auswählen.
**Parameterwerte abfragen**
`prompt=none`
Amazon Cognito setzt die Authentifizierung für Benutzer, die über eine gültige authentifizierte Sitzung verfügen, im Hintergrund fort. Mit dieser Aufforderung können sich Benutzer unbeaufsichtigt zwischen verschiedenen App-Clients in Ihrem Benutzerpool authentifizieren. Wenn der Benutzer noch nicht authentifiziert ist, gibt der Autorisierungsserver einen Fehler zurück. `login_required`
`prompt=login`
Amazon Cognito verlangt von Benutzern, sich erneut zu authentifizieren, auch wenn sie eine bestehende Sitzung haben. Senden Sie diesen Wert, wenn Sie die Identität des Benutzers erneut überprüfen möchten. Authentifizierte Benutzer, die über eine bestehende Sitzung verfügen, können zur Anmeldung zurückkehren, ohne dass diese Sitzung ungültig wird. Wenn sich ein Benutzer, der eine bestehende Sitzung hat, erneut anmeldet, weist Amazon Cognito ihm ein neues Sitzungscookie zu. Dieser Parameter kann auch an Ihren weitergeleitet werden. IdPs IdPsdie diesen Parameter akzeptieren, fordern auch einen neuen Authentifizierungsversuch vom Benutzer an.
`prompt=select_account`
Dieser Wert hat keine Auswirkung auf die lokale Anmeldung und muss in Anfragen eingereicht werden, die zu IdPs umleiten. Wenn dieser Parameter in Ihrer Autorisierungsanfrage enthalten ist, wird er `prompt=select_account` zum URL-Pfad für das IdP-Umleitungsziel hinzugefügt. Wenn dieser Parameter IdPs unterstützt wird, fordern sie die Benutzer auf, das Konto auszuwählen, mit dem sie sich anmelden möchten.
`prompt=consent`
Dieser Wert hat keine Auswirkung auf die lokale Anmeldung und muss in Anfragen eingereicht werden, die zu IdPs umleiten. Wenn dieser Parameter in Ihrer Autorisierungsanfrage enthalten ist, wird er `prompt=consent` zum URL-Pfad für das IdP-Umleitungsziel hinzugefügt. Wenn dieser Parameter IdPs unterstützt wird, fordern sie die Zustimmung des Benutzers an, bevor sie zurück zu Ihrem Benutzerpool weiterleiten.
Wenn Sie den `prompt` Parameter in Ihrer Anfrage weglassen, folgt die verwaltete Anmeldung dem Standardverhalten: Benutzer müssen sich anmelden, es sei denn, ihr Browser hat ein gültiges Sitzungscookie für die verwaltete Anmeldung. Sie können beispielsweise mehrere Werte für `prompt` mit einem Leerzeichen als Trennzeichen kombinieren. `prompt=login consent`
**`resource`**
Optional.
Der Bezeichner einer Ressource, die Sie an das Zugriffstoken im Anspruch binden möchten. `aud` Wenn Sie diesen Parameter angeben, überprüft Amazon Cognito, ob es sich bei dem Wert um eine URL handelt, und legt die Zielgruppe des resultierenden Zugriffstokens auf die angeforderte Ressource fest. Sie können einen [Benutzerpool-Ressourcenserver](cognito-user-pools-define-resource-servers.md) mit einer Kennung in einem URL-Format oder einer URL Ihrer Wahl anfordern. Die Werte für diesen Parameter müssen mit `https://``http://localhost`, oder einem benutzerdefinierten URL-Schema wie beginnen`myapp://`.
Die Ressourcenbindung ist in [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) definiert. [Weitere Informationen zu Ressourcenservern und Ressourcenbindung finden Sie unter Ressourcenbindung.](cognito-user-pools-define-resource-servers.md#cognito-user-pools-resource-binding)
## Beispiel: Erteilung eines Autorisierungscodes
Dies ist ein Beispiel für eine Anfrage zur Erteilung eines Autorisierungscodes.
Die folgende Anfrage initiiert eine Sitzung zum Abrufen eines Autorisierungscodes, den Ihr Benutzer an Ihre App am `redirect_uri` Ziel weitergibt. In dieser Sitzung werden Bereiche für Benutzerattribute und für den Zugriff auf Amazon Cognito-Self-Service-API-Operationen angefordert.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin
```
Der Amazon-Cognito-Authentifikationsserver leitet Autorisierungs-Code und -Status zurück an Ihre App. Der Autorisierungscode ist fünf Minuten gültig.
```
HTTP/1.1 302 Found
Location: https://www.example.com?code=a1b2c3d4-5678-90ab-cdef-EXAMPLE11111&state=abcdefg
```
## Beispiel: Erteilung eines Autorisierungscodes mit PKCE
In diesem Beispielablauf wird eine Autorisierungscode-Erteilung mit [PKCE](using-pkce-in-authorization-code.md#using-pkce-in-authorization-code.title) durchgeführt.
Diese Anfrage fügt einen `code_challenge` Parameter hinzu. Um den Austausch eines Codes gegen ein Token abzuschließen, müssen Sie den `code_verifier` Parameter in Ihre Anfrage an den `/oauth2/token` Endpunkt aufnehmen.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin&
code_challenge_method=S256&
code_challenge=a1b2c3d4...
```
Der Autorisierungsserver leitet mit dem Autorisierungscode und dem Status zurück zu Ihrer Anwendung. Ihre Anwendung verarbeitet den Autorisierungscode und tauscht ihn gegen Token ein.
```
HTTP/1.1 302 Found
Location: https://www.example.com?code=a1b2c3d4-5678-90ab-cdef-EXAMPLE11111&state=abcdefg
```
## Beispiel: erfordert eine erneute Authentifizierung mit `prompt=login`
Die folgende Anfrage fügt einen `prompt=login` Parameter hinzu, nach dem sich der Benutzer erneut authentifizieren muss, auch wenn er bereits eine Sitzung hat.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin&
prompt=login
```
Der Autorisierungsserver leitet zum [Anmeldeendpunkt](login-endpoint.md) weiter und erfordert eine erneute Authentifizierung.
```
HTTP/1.1 302 Found Location: https://mydomain.auth.us-east-1.amazoncognito.com/login?response_type=code&client_id=1example23456789&redirect_uri=https://www.example.com&state=abcdefg&scope=openid+profile+aws.cognito.signin.user.admin&prompt=login
```
## Beispiel: unbeaufsichtigte Authentifizierung mit `prompt=none`
Die folgende Anfrage fügt einen `prompt=none` Parameter hinzu, der im Hintergrund überprüft, ob der Benutzer eine gültige Sitzung hat.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=openid+profile+aws.cognito.signin.user.admin&
prompt=none
```
Wenn keine gültige Sitzung vorhanden ist, gibt der Autorisierungsserver einen Fehler an die Umleitungs-URI zurück
```
HTTP/1.1 302 Found Location: https://www.example.com?error=login_required&state=abcdefg
```
Wenn eine gültige Sitzung besteht, gibt der Autorisierungsserver einen Autorisierungscode zurück.
```
HTTP/1.1 302 Found Location: https://www.example.com?code=AUTHORIZATION_CODE&state=abcdefg
```
## Beispiel: Erteilung eines Autorisierungscodes mit Ressourcenbindung
Die folgende Anfrage fügt einen `resource` Parameter hinzu, um das Zugriffstoken an einen bestimmten Ressourcenserver zu binden. Das resultierende Zugriffstoken schafft die Voraussetzungen dafür, dass die Ziel-API überprüft, ob es sich um die Zielgruppe der Anfrage des authentifizierten Benutzers handelt.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=code&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=solar-system-data-api.example.com/asteroids.add&
resource=https://solar-system-data-api.example.com
```
Der Autorisierungsserver gibt einen Autorisierungscode zurück, der zu einem Zugriffstoken mit dem `aud` Anspruch von `https://solar-system-data-api.example.com` führt.
```
HTTP/1.1 302 Found Location: https://www.example.com?code=AUTHORIZATION_CODE&state=abcdefg
```
## Beispiel: Token-Erteilung (implizit) ohne Geltungsbereich `openid`
Dieser Beispielablauf generiert eine implizite Gewährung und kehrt JWTs direkt zur Sitzung des Benutzers zurück.
Die Anfrage bezieht sich auf eine implizite Erteilung von Ihrem Autorisierungsserver. Sie fordert Bereiche im Zugriffstoken an, die Self-Service-Vorgänge für Benutzerprofile autorisieren.
```
GET https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=token&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin
```
Der Autorisierungsserver leitet nur mit einem Zugriffstoken zurück zu Ihrer Anwendung. Da der `openid`-Bereich nicht angefordert wurde, gibt Amazon Cognito kein ID-Token aus. Außerdem gibt Amazon Cognito in diesem Flow kein Aktualisierungs-Token aus.
```
HTTP/1.1 302 Found
Location: https://example.com/callback#access_token=eyJra456defEXAMPLE&token_type=bearer&expires_in=3600&state=STATE
```
## Beispiel: Token-Erteilung (implizit) mit Gültigkeitsbereich `openid`
Dieser Beispielablauf generiert eine implizite Gewährung und gibt Token an den Browser des Benutzers zurück.
Die Anfrage bezieht sich auf eine implizite Erteilung durch Ihren Autorisierungsserver. Sie fordert Bereiche im Zugriffstoken an, die den Zugriff auf Benutzerattribute und Self-Service-Operationen autorisieren.
```
GET
https://mydomain.auth.us-east-1.amazoncognito.com/oauth2/authorize?
response_type=token&
client_id=1example23456789&
redirect_uri=https://www.example.com&
state=abcdefg&
scope=aws.cognito.signin.user.admin+openid+profile
```
Der Autorisierungsserver leitet mit dem Zugriffstoken und dem ID-Token zurück zu Ihrer Anwendung (da der `openid` Bereich enthalten war):
```
HTTP/1.1 302 Found
Location: https://www.example.com#id_token=eyJra67890EXAMPLE&access_token=eyJra12345EXAMPLE&token_type=bearer&expires_in=3600&state=abcdefg
```
## Beispiele für negative Antworten
Amazon Cognito lehnt Ihre Anfrage möglicherweise ab. Negative Anfragen enthalten einen HTTP-Fehlercode und eine Beschreibung, anhand derer Sie Ihre Anforderungsparameter korrigieren können. Im Folgenden finden Sie Beispiele für negative Antworten.
+ Wenn `client_id` und gültig `redirect_uri` sind, die Anforderungsparameter jedoch nicht korrekt formatiert sind, leitet der Authentifizierungsserver den Fehler an den des Clients weiter `redirect_uri` und fügt eine Fehlermeldung an einen URL-Parameter an. Im Folgenden finden Sie Beispiele für eine falsche Formatierung.
+ Die Anfrage enthält keinen `response_type` Parameter.
+ Die Autorisierungsanfrage lieferte einen `code_challenge` Parameter, aber keinen `code_challenge_method` Parameter.
+ Der Wert des `code_challenge_method` Parameters ist nicht`S256`.
Im Folgenden finden Sie die Antwort auf eine Beispielanfrage mit falscher Formatierung.
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request
```
+ Wenn der Client eine Anfrage `code` oder `token` eingibt`response_type`, aber keine Genehmigung für diese Anfragen hat, kehrt der Amazon Cognito Cognito-Autorisierungsserver wie folgt `unauthorized_client` zum Client-Autorisierungsserver zurück: `redirect_uri`
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=unauthorized_client
```
+ Falls die Anforderung des Clients unbekannt, falsch formatiert oder ungültig ist, sollte der Amazon-Cognito-Autorisierungsserver `invalid_scope` folgendermaßen zur `redirect_uri` des Clients zurückgeben:
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_scope
```
+ Wenn auf dem Server ein unerwarteter Fehler auftritt, kehrt der Authentifizierungsserver `server_error` zum Server des `redirect_uri` Clients zurück. Da der HTTP 500-Fehler nicht an den Client gesendet wird, wird der Fehler nicht im Browser des Benutzers angezeigt. Der Autorisierungsserver gibt den folgenden Fehler zurück.
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=server_error
```
+ Wenn Amazon Cognito sich über einen Verbund mit einem Drittanbieter authentifiziert IdPs, kann es bei Amazon Cognito zu Verbindungsproblemen kommen, wie z. B. die folgenden:
+ Wenn es bei der Token-Anforderung vom IdP zu einem Verbindungs-Timeout kommt, leitet der Authentifizierungsserver den Fehler wie folgt an den `redirect_uri` des Clients weiter:
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Timeout+occurred+in+calling+IdP+token+endpoint
```
+ Wenn beim Aufrufen des `jwks_uri` Endpunkts zur Überprüfung des ID-Tokens ein Verbindungs-Timeout auftritt, leitet der Authentifizierungsserver mit einem Fehler wie folgt an den des Clients weiter: `redirect_uri`
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=error_description=Timeout+in+calling+jwks+uri
```
+ Bei der Authentifizierung über einen Verbund mit einem Drittanbieter IdPs geben die Anbieter möglicherweise Fehlerantworten zurück. Dies kann auf Konfigurationsfehler oder andere Gründe zurückzuführen sein, z. B. auf die folgenden:
+ Wenn eine Fehlermeldung von anderen Anbietern empfangen wird, leitet der Authentifizierungsserver den Fehler wie folgt an den `redirect_uri` des Clients weiter:
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=[IdP name]+Error+-+[status code]+error getting token
```
+ Wenn eine Fehlerantwort von Google empfangen wird, leitet der Authentifizierungsserver den Fehler wie folgt an den `redirect_uri` des Clients weiter:
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Google+Error+-+[status code]+[Google-provided error code]
```
+ Wenn Amazon Cognito bei der Verbindung zu einem externen IdP auf eine Kommunikationsausnahme stößt, leitet der Authentifizierungsserver mit einer der folgenden Meldungen `redirect_uri` mit einem Fehler an den des Kunden weiter:
+
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Connection+reset
```
+
```
HTTP 1.1 302 Found Location: https://client_redirect_uri?error=invalid_request&error_description=Read+timed+out
```
# Der Endpunkt des Token-Ausstellers
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
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
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
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
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
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
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
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
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
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
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`.
# Der Endpunkt der Benutzerattribute
Wo OIDC ID-Token ausgibt, die Benutzerattribute enthalten, implementiert OAuth 2.0 den `/oauth2/userInfo` Endpunkt. Ein authentifizierter Benutzer oder Client erhält ein Zugriffstoken mit einem Anspruch. `scopes` Dieser Anspruch bestimmt die Attribute, die der Autorisierungsserver zurückgeben soll. Wenn eine Anwendung dem `userInfo` Endpunkt ein Zugriffstoken vorlegt, gibt der Autorisierungsserver einen Antworttext zurück, der die Benutzerattribute enthält, die innerhalb der durch die Gültigkeitsbereiche der Zugriffstoken festgelegten Grenzen liegen. Ihre Anwendung kann Informationen über einen Benutzer vom `userInfo` Endpunkt abrufen, sofern sie über ein gültiges Zugriffstoken mit mindestens einem `openid` Geltungsbereichsanspruch verfügt.
Der Endpunkt `userInfo` ist ein OIDC-[UserInfo-Endpunkt](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) (OpenID-Connect). Sie reagiert mit Benutzerattributen, wenn Dienstanbieter Zugriffstoken vorlegen, die Ihr [Token-Endpunkt](token-endpoint.md) ausgegeben hat. Die Bereiche im Zugriffstoken Ihres Benutzers definieren die Benutzerattribute, die der UserInfo-Endpunkt in seiner Antwort zurückgibt. Der `openid`-Gültigkeitsbereich muss einer der Zugriffstokenansprüche sein.
Amazon Cognito gibt Zugriffs-Token als Antwort auf Benutzerpool-API-Anfragen wie [https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_InitiateAuth.html) aus. Da sie keine Bereiche enthalten, akzeptiert der userInfo-Endpunkt diese Zugriffstoken nicht. Stattdessen müssen Sie Zugriffstoken von Ihrem Token-Endpunkt vorlegen.
Ihr OAuth 2.0-Dritt-Identity-Provider (IdP) hostet auch einen userInfo Endpunkt. Wenn sich Ihr Benutzer bei diesem IdP authentifiziert, tauscht Amazon Cognito im Hintergrund einen Autorisierungscode mit dem IdP-Endpunkt aus. `token` Ihr Benutzerpool übergibt das IdP-Zugriffstoken, um den Abruf von Benutzerinformationen vom IdP-Endpunkt zu autorisieren. `userInfo`
Die Bereiche im Zugriffstoken eines Benutzers werden durch den `scopes` Anforderungsparameter in Authentifizierungsanforderungen oder durch die Bereiche bestimmt, die der [Lambda-Trigger vor der Token-Generierung hinzufügt](user-pool-lambda-pre-token-generation.md). Sie können Zugriffstoken dekodieren und `scope` Ansprüche untersuchen, um herauszufinden, welche Bereiche der Zugriffskontrolle sie enthalten. Im Folgenden sind einige Bereichskombinationen aufgeführt, die sich auf die vom Endpunkt zurückgegebenen Daten auswirken. `userInfo` Der reservierte Amazon Cognito Cognito-Bereich `aws.cognito.signin.user.admin` hat keine Auswirkung auf die von diesem Endpunkt zurückgegebenen Daten.Beispielbereiche im Zugriffstoken und ihre Auswirkung auf die Antwort `userInfo`
**`openid`**
Gibt eine Antwort mit allen Benutzerattributen zurück, die der App-Client lesen kann.
**`openid profile`**
Gibt die Benutzerattribute`name`,`family_name`,`given_name`,`middle_name`,`nickname`,`preferred_username`,`profile`,`picture`,`website`,`gender`,`birthdate`, `zoneinfo``locale`, und zurück`updated_at`. Gibt auch [benutzerdefinierte Attribute](user-pool-settings-attributes.md#user-pool-settings-custom-attributes) zurück. In App-Clients, die keinen Lesezugriff auf jedes Attribut haben, entspricht die Antwort auf diesen Bereich allen Attributen innerhalb der Spezifikation, auf die Ihr App-Client Lesezugriff hat.
**`openid email`**
Gibt grundlegende Profilinformationen und die `email_verified` Attribute `email` und zurück.
**`openid phone`**
Gibt grundlegende Profilinformationen und die `phone_number_verified` Attribute `phone_number` und zurück.
## GET /oauth2/userInfo
Ihre Anwendung generiert Anfragen an diesen Endpunkt direkt, nicht über einen Browser.
Weitere Informationen finden Sie unter [UserInfo-Endpunkt](http://openid.net/specs/openid-connect-core-1_0.html#UserInfo) in der Spezifikation zu OpenID Connect (OIDC).
**Topics**
+ [
## GET /oauth2/userInfo
](#get-userinfo)
+ [
## Anfrageparameter im Header
](#get-userinfo-request-header-parameters)
+ [
## Beispiel — Anfrage
](#get-userinfo-positive-exchanging-authorization-code-for-userinfo-sample-request)
+ [
## Beispiel — positive Antwort
](#get-userinfo-response-sample)
+ [
## Beispiel für negative Antworten
](#get-userinfo-negative)
## Anfrageparameter im Header
**`Authorization: Bearer `**
Übergeben Sie das Zugriffstoken im Autorisierungsheader-Feld.
Erforderlich
## Beispiel — Anfrage
```
GET /oauth2/userInfo HTTP/1.1
Content-Type: application/x-amz-json-1.1
Authorization: Bearer eyJra12345EXAMPLE
User-Agent: [User agent]
Accept: */*
Host: auth.example.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
```
## Beispiel — positive Antwort
```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Content-Length: [Integer]
Date: [Timestamp]
x-amz-cognito-request-id: [UUID]
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Server: Server
Connection: keep-alive
{
"sub": "[UUID]",
"email_verified": "true",
"custom:mycustom1": "CustomValue",
"phone_number_verified": "true",
"phone_number": "+12065551212",
"email": "bob@example.com",
"username": "bob"
}
```
Eine Liste der OIDC-Ansprüche finden Sie unter [Standardansprüche](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Derzeit gibt Amazon Cognito die Werte für `email_verified` und `phone_number_verified` als Zeichenfolgen zurück.
## Beispiel für negative Antworten
### Beispiel — schlechte Anfrage
```
HTTP/1.1 400 Bad Request
WWW-Authenticate: error="invalid_request",
error_description="Bad OAuth2 request at UserInfo Endpoint"
```
**`invalid_request`**
In der Anfrage fehlt ein erforderlicher Parameter, sie enthält einen nicht unterstützten Parameterwert oder sie ist anderweitig falsch formatiert.
### Beispiel — schlechtes Token
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="Access token is expired, disabled, or deleted, or the user has globally signed out."
```
**`invalid_token`**
Das Zugriffstoken ist abgelaufen, gesperrt, falsch formatiert oder ungültig.
# Der Endpunkt für den Token-Widerruf
Benutzer, die in ihrer Sitzung über ein Aktualisierungstoken verfügen, haben etwas Ähnliches wie ein Browser-Cookie. Sie können ihre bestehende Sitzung verlängern, solange das Aktualisierungstoken gültig ist. Anstatt einen Benutzer aufzufordern, sich nach Ablauf seiner ID oder seines Zugriffstokens anzumelden, kann Ihre Anwendung das Aktualisierungstoken verwenden, um neue, gültige Token abzurufen. Sie können jedoch extern festlegen, dass die Sitzung eines Benutzers beendet werden soll, oder der Benutzer kann sich dafür entscheiden, seine aktuelle Sitzung zu vergessen. Zu diesem Zeitpunkt können Sie das Aktualisierungstoken widerrufen, sodass der Benutzer seine Sitzung nicht länger fortführen kann.
Der `/oauth2/revoke` Endpunkt widerruft das Zugriffstoken eines Benutzers, das Amazon Cognito ursprünglich mit dem von Ihnen bereitgestellten Aktualisierungstoken ausgestellt hat. Dieser Endpunkt widerruft auch das Aktualisierungstoken selbst und alle nachfolgenden Zugriffs- und Identitätstoken desselben Aktualisierungstoken. Nachdem der Endpunkt die Token gesperrt hat, können Sie die widerrufenen Zugriffstoken nicht mehr verwenden, um auf die Amazon Cognito Cognito-Token zuzugreifen APIs , die authentifiziert werden.
## POST /oauth2/revoke
Der `/oauth2/revoke` Endpunkt unterstützt ausschließlich `HTTPS POST`. Der Benutzer-Pool sendet Anforderungen direkt an diesen Endpunkt und nicht über den System-Browser.
### Anfrageparameter im Header
**`Authorization`**
Wenn Ihr App-Client über einen geheimen Client-Schlüssel verfügt, muss die Anwendung dessen `client_id` und `client_secret` im Autorisierungsheader über die Basic-HTTP-Autorisierung weitergeben. Der Geheim-Schlüssel ist [Basic](https://en.wikipedia.org/wiki/Basic_access_authentication#Client_side) `Base64Encode(client_id:client_secret)`.
**`Content-Type`**
Es muss sich immer um handeln `'application/x-www-form-urlencoded'`.
#### Anfrageparameter im Fließtext
**`token`**
(Erforderlich) Das Aktualisierungstoken, das der Client widerrufen möchte. Die Anforderung widerruft auch alle Zugriffstoken, die Amazon Cognito mit diesem Aktualisierungstoken ausgegeben hat.
Erforderlich
**`client_id`**
(Optional) Die App-Client-ID für das Token, das Sie widerrufen möchten.
Erforderlich, wenn der Client öffentlich ist und keinen Geheim-Schlüssel hat.
## Beispiel für einen Widerrufsanforderung
Diese Sperranforderung widerruft ein Aktualisierungstoken für einen App-Client, der keinen geheimen Clientschlüssel hat. Notieren Sie sich den `client_id` Parameter im Hauptteil der Anfrage.
```
POST /oauth2/revoke HTTP/1.1
Host: mydomain.auth.us-east-1.amazoncognito.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
token=2YotnFZFEjr1zCsicMWpAA&
client_id=1example23456789
```
Diese Sperranforderung widerruft ein Aktualisierungstoken für einen App-Client, der *über einen geheimen Clientschlüssel verfügt*. Notieren Sie sich den `Authorization` Header, der eine verschlüsselte Client-ID und einen geheimen Client-Schlüssel enthält, aber nicht `client_id` im Hauptteil der Anfrage.
```
POST /oauth2/revoke HTTP/1.1
Host: mydomain.auth.us-east-1.amazoncognito.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=2YotnFZFEjr1zCsicMWpAA
```
## Antwort auf einen Fehler
Eine erfolgreiche Antwort enthält einen leeren Körper. Die Fehlerantwort ist ein JSON-Objekt mit einem `error`-Feld und in manchen Fällen ein `error_description`-Feld.
**Endpunktfehler**
+ Ihnen werden HTTP 400 und der Fehler `invalid_request` angezeigt, wenn das Token in der Anforderung nicht vorhanden ist oder wenn die Funktion für den App-Client deaktiviert ist.
+ Wenn das Token, das Amazon Cognito in der Widerrufsanfrage gesendet hat, kein Aktualisierungstoken ist, erhalten Sie ein HTTP 400 und den Fehler `unsupported_token_type`.
+ Wenn die Client-Anmeldeinformationen nicht gültig sind, wird Ihnen HTTP 401 und der Fehler `invalid_client` angezeigt.
+ Wenn das Token widerrufen wurde oder der Client ein ungültiges Token übermittelt hat, erhalten Sie ein HTTP 200-OK.
# Der IdP-SAML-Assertion-Endpunkt
Der `/saml2/idpresponse` empfängt SAML-Assertionen. Bei der service-provider-initiated (SP-initiierten) Anmeldung interagiert Ihre Anwendung nicht direkt mit diesem Endpunkt — Ihr SAML 2.0-Identitätsanbieter (IdP) leitet Ihren Benutzer mit seiner SAML-Antwort hierher weiter. Für die SP-initiierte Anmeldung konfigurieren Sie Ihren IdP mit dem Pfad zu Ihrer `saml2/idpresponse` als Assertion Consumer Service (ACS) -URL. Weitere Informationen zur Sitzungsinitiierung finden Sie unter. [Initiierung der SAML-Sitzung in Amazon-Cognito-Benutzerpools](cognito-user-pools-SAML-session-initiation.md)
Rufen Sie bei der IDP-initiierten Anmeldung Anfragen an diesen Endpunkt in Ihrer Anwendung auf, nachdem Sie sich bei Ihrem SAML 2.0-Anbieter als Benutzer angemeldet haben. Ihre Benutzer melden sich mit Ihrem IdP in ihrem Browser an, dann sammelt Ihre Anwendung die SAML-Assertion und sendet sie an diesen Endpunkt. Sie müssen SAML-Assertionen im Hauptteil einer Anfrage über HTTPS einreichen. `HTTP POST` Der Hauptteil Ihrer `POST` Anfrage muss aus einem `SAMLResponse` Parameter und einem `Relaystate` Parameter bestehen. Weitere Informationen finden Sie unter [Implementieren Sie die IDP-initiierte SAML-Anmeldung](cognito-user-pools-SAML-session-initiation.md#cognito-user-pools-SAML-session-initiation-idp-initiation).
Der `saml2/idpresponse` Endpunkt kann SAML-Assertionen mit einer Länge von bis zu 100.000 Zeichen akzeptieren.
## BEITRAG `/saml2/idpresponse`
Um den `/saml2/idpresponse` Endpunkt bei einer vom IDP initiierten Anmeldung zu verwenden, generieren Sie eine POST-Anforderung mit Parametern, die Ihrem Benutzerpool Informationen über die Sitzung Ihres Benutzers liefern.
+ Der App-Client, bei dem sie sich anmelden möchten.
+ Die Callback-URL, unter der sie landen möchten.
+ Die OAuth 2.0-Bereiche, die sie im Zugriffstoken Ihres Benutzers anfordern möchten.
+ Der IdP, der die Anmeldeanforderung initiiert hat.
### Vom IDP initiierte Anfragetextparameter
*SAMLResponse*
Eine Base64-kodierte SAML-Assertion von einem IdP, der einem gültigen App-Client und einer IdP-Konfiguration in Ihrem Benutzerpool zugeordnet ist.
*RelayState*
Ein `RelayState` Parameter enthält die Anforderungsparameter, die Sie andernfalls an den Endpunkt übergeben würden. `oauth2/authorize` Detaillierte Informationen zu diesen Parametern finden Sie unter [Autorisieren des Endpunkts](authorization-endpoint.md).
*response\$1type*
Der OAuth Zuschusstyp 2.0.
*Client-ID*
Die App-Client-ID).
*redirect\$1uri*
Die URL, an die der Authentifizierungsserver den Browser nach der Autorisierung des Benutzers durch Amazon Cognito weiterleitet.
*Identitätsanbieter*
Der Name des Identitätsanbieters, an den Sie Ihren Benutzer weiterleiten möchten.
*Idp-Identifier*
Die Kennung des Identitätsanbieters, zu dem Sie Ihren Benutzer weiterleiten möchten.
*scope*
Die OAuth 2.0-Bereiche, die Ihr Benutzer vom Autorisierungsserver anfordern soll.
### Beispielanfragen mit positiven Antworten
**Beispiel — POST-Anfrage**
Die folgende Anfrage bezieht sich auf die Gewährung eines Autorisierungscodes für einen Benutzer von IdP `MySAMLIdP` im App-Client`1example23456789`. Der Benutzer leitet `https://www.example.com` mit seinem Autorisierungscode weiter, der gegen Token eingetauscht werden kann, die ein Zugriffstoken mit den Bereichen OAuth 2.0 enthalten `openid``email`, und. `phone`
```
POST /saml2/idpresponse HTTP/1.1
User-Agent: USER_AGENT
Accept: */*
Host: example.auth.us-east-1.amazoncognito.com
Content-Type: application/x-www-form-urlencoded
SAMLResponse=[Base64-encoded SAML assertion]&RelayState=identity_provider%3DMySAMLIdP%26client_id%3D1example23456789%26redirect_uri%3Dhttps%3A%2F%2Fwww.example.com%26response_type%3Dcode%26scope%3Demail%2Bopenid%2Bphone
```
**Beispiel — Antwort**
Das Folgende ist die Antwort auf die vorherige Anfrage.
```
HTTP/1.1 302 Found
Date: Wed, 06 Dec 2023 00:15:29 GMT
Content-Length: 0
x-amz-cognito-request-id: 8aba6eb5-fb54-4bc6-9368-c3878434f0fb
Location: https://www.example.com?code=[Authorization code]
```