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 Server mit Liberty mit aktiviertem OpenID Connect hat unter der folgenden URL Zugriff auf den OpenID Connect-Introspektionsendpunkt:

 https://server.example.com:443/oidc/endpoint/<Providername>/introspect
Fehler vermeiden: Wenn Sie einen Proxy für abgehende Anforderungen verwenden, beachten Sie, dass die OpenID Connect-RP keine Möglichkeit bereitstellt, Anforderungen automatisch über einen Proxy-Host weiterzuleiten.

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

  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

Dateiname: twlp_oidc_introspection_endpoint.html