Introspektionsendpunkt für OpenID Connect aufrufen

Der Introspektionsendpunkt ermöglicht Inhabern von Zugriffstokens, eine Gruppe von Metadaten zu einem Zugriffstoken von dem OpenID Connect-Provider anzufordern, der das Zugriffstoken ausgegeben hat. Voraussetzung ist, dass das Zugriffstoken von OpenID Connect oder von der OAuth-Authentifizierung abgerufen wurde.

Vorbereitende Schritte

Wenn ein Ressourcenservice oder eine Clientanwendung den Introspektionsendpunkt aufruft, muss der Service bzw. die Anwendung sich als normaler OAuth 2.0-Client beim OpenID Connect-Server registrieren. Die registrierten Clientmetadaten müssen das Attribut introspectTokens = true einschließen.

Informationen zu diesem Vorgang

Informationen, die in Zugriffstokens enthalten sind, die in OpenID und OAuth 2.0 verwendet werden, sind für Clients nicht transparent. Das kann geschützten Ressourcen oder Clients ermöglichen, Berechtigungsentscheidungen zu treffen, die auf den Metadaten zum Zugriffstoken basieren, die vom OpenID Connect-Provider zurückgegeben werden.

Ein Liberty-Server mit aktiviertem OpenID Connect hat unter der folgenden URL Zugriff auf den OpenID Connect-Introspektionsendpunkt:

 https://server.example.com:443/oidc/endpoint/<Providername>/introspect
Anmerkung: In diesem Beispiel ist 443 der erwartete SSL-Port des OP.

Vorgehensweise

  1. Konfigurieren Sie die Clientauthentifizierung mit der Client-ID und dem Kennwort für einen registrierten OpenID Connect-Client im HTTP-Basisberechtigungsheader einer GET- oder POST-Anforderung. Die Client-ID und das Kennwort werden mit dem Codierungsalgorithmus application/x-www-form-urlencoded codiert. Die codierte Client-ID wird als Benutzername verwendet und das codierte Kennwort als Kennwort.
  2. Schließen Sie den Zeichenfolgewert für das Zugriffstoken als Parameter in die an den Introspektionsendpunkt gerichtete GET- oder POST-Anforderung ein.
  3. Senden Sie die GET- oder POST-Anforderung an die Introspektionsendpunkt-URL.

Ergebnisse

Nachdem Sie diese Schritte ausgeführt haben, haben Sie eine gültige HTTP-Anforderung, die an den Introspektionsendpunkt gesendet wird, wie im Abschnitt "Beispiele" gezeigt.

Bei gültigen Anforderungen gibt der Introspektionsendpunkt die Antwort HTTP 200 mit einem JSON-Objekt im Format application/json zurück. Das Objekt enthält, je nachdem, ob das Zugriffstoken aktiv oder abgelaufen ist, folgende Informationen.

Ist das Zugriffstoken aktiv, gibt der Endpunkt active:true und die folgenden zusätzlichen Informationen im JSON-Objekt zurück:

  • active: Boolscher Indikator, der angibt, ob das Zugriffstoken aktiv ist.
  • client_id: Client-ID des OpenID Connect-Clients, der das Zugriffstoken angefordert hat.
  • sub: Der Ressourceneigner, der das Zugriffstoken berechtigt hat.
  • scope: Eine durch Leerzeichen getrennte Liste mit Geltungsbereichen, die dem Zugriffstoken zugeordnet sind.
  • iat: Eine in Ganzzahlen angegebene Zeitmarke, gemessen in Sekunden seit dem 1. Januar 1970 UTC, die angibt, wann das Zugriffstoken ausgegeben wurde.
  • exp: Eine in Ganzzahlen angegebene Zeitmarke, gemessen in Sekunden seit dem 1. Januar 1970 UTC, die angibt, wann das Zugriffstoken ablaufen wird.
  • realmName: Realmname des Ressourceneigners.
  • uniqueSecurityName: Eindeutiger Sicherheitsname des Ressourceneigners.
  • tokenType: Typ des Zugriffstokens. Für OpenID Connect ist dieser Wert Bearer.
  • grant_type: Eine Zeichenfolge, die den Grant-Typ angibt, mit dem das Zugriffstoken generiert wurde. Gültige Werte sind: authorization_code, password, refresh_token, client_credentials, resource_owner, implicit und urn:ietf:params:oauth:grant-type:jwt-bearer.

Wenn das Zugriffstoken abgelaufen ist, die angegebene Authentifizierung jedoch gültig ist oder wenn das Zugriffstoken nicht den richtigen Typ hat, gibt der Endpunkt active:false im JSON-Objekt zurück.

Anmerkung: Damit ein Client oder Ressourcentyp die Introspektion des Zugriffstokens ausführt, muss der Client oder Ressourcenservice sich als Client beim OpenID Connect-Provider registrieren und in den Clientmetadaten muss introspect_tokens auf true gesetzt sein.

Beispiel

Es folgen Beispiele für ein aktives und abgelaufenes Zugriffstoken mit einer Anforderung.

Beispielanforderung:

  POST /register HTTP/1.1
 Accept: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
     token=SOYleDziTitHeKcodp6vqEmRwKPjz3lFZTcsQtVC

Beispielantwort für ein aktives Zugriffstoken:

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
{  
   "exp"                : 1415307710,
   "realmName"          : "BasicRealm",
   "sub"                : "testuser",
   "scope"              : "openid scope2 scope1",
   "grant_type"         : "authorization_code",
   "uniqueSecurityName" : "testuser",
   "active"             : true,
   "token_type"         : "Bearer",
   "client_id"          : "pclient01",
   "iat"                : 1415307700
}

Beispielantwort für ein abgelaufenes Zugriffstoken:

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
 {
     "active":"false"
 }

Symbol das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 01.12.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_oidc_introspection_endpoint
Dateiname: twlp_oidc_introspection_endpoint.html