Tokenendpunkt für OpenID Connect aufrufen
Im OpenID Connect-Berechtigungscodeablauf verwendet ein Client den Tokenendpunkt, um ein ID-Token, ein Zugriffstoken und ein Aktualisierungstoken abzurufen.
Vorbereitende Schritte
Informationen zu diesem Vorgang
Der Tokenendpunkt akzeptiert eine Anforderung von dem Client, der einen Berechtigungscode einschließt, der vom Berechtigungsendpunkt an den Client ausgegeben wird. Wenn der Berechtigungscode validiert wird, werden die entsprechenden Token in einer Antwort an den Client zurückgegeben.
Der Tokenendpunkt wird nicht im impliziten Ablauf von OpenID Connect verwendet.
Ein Server mit Liberty mit aktiviertem OpenID Connect hat unter der folgenden URL Zugriff auf den OpenID Connect-Tokenendpunkt:
https://server.example.com:443/oidc/endpoint/<Providername>/token
Wenn Sie einen Proxy für den Zugriff auf OpenID Connect Provider (OP) verwenden müssen, muss der Wert, den Sie für eine beliebige auf OP bezogene URL-Eigenschaft eingeben, den Proxy-Host und Port und nicht den Host und Port des externen OP enthalten.
In den meisten Fällen können Sie den OP-Host und Port durch den Proxy-Host und Port ersetzen. Die URL, die Sie eingeben, muss für die RP und den Client (Browser oder Anwendung) sichtbar sein. Weitere Informationen darüber, wie Sie die richtige zu verwendende URL ermitteln, erhalten Sie von Ihrem Proxy-Administrator.
Der Client in diesem Beispiel erwartet, dass der SSL-Port auf 443 gesetzt ist.
Vorgehensweise
Ergebnisse
Wenn der OpenID Connect-Provider die vom Client empfangene Tokenanforderung validiert, gibt der OpenID Connect-Provider die Antwort "HTTP 200" mit einem JSON-Objekt im Format application/json an den Client zurück. Die Antwort enthält das ID-Token, das Zugriffstoken und das Aktualisierungstoken zusammen mit den folgenden zusätzlichen Parametern:
- token_type: OAuth 2.0-Tokentyp. Für OpenID Connect ist dieser Wert Bearer.
- expires_in: Ablaufzeit des Zugriffstokens in Sekunden seit Generierung der Antwort.
Für alle Antworten des Tokenendpunkts, die Token, geheime Schlüssel oder andere sensible Informationen enthalten, ist der Wert des Cache-Control-Headers auf no-store und der Wert des Pragma-Headers auf no-cache gesetzt.
.Beispiel
Beispielanforderung:
POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
Beispielantwort:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJ ... zcifQ.ewo ... NzAKfQ.ggW8h ... Mzqg"
}