Tokenvalidierung

Warum validieren wir Token? Wenn Ihre Webanwendung die Zugangsdaten direkt prüft, prüft sie, ob der angezeigte Benutzername und das angezeigte Kennwort den von Ihnen verwalteten Daten entsprechen. Wenn Sie eine beanspruchungsbasierte Identität verwenden, müssen Sie diesen Job an einen Identitätsprovider auslagern.

Die Verantwortung wechselt von der Prüfung von Rohzugangsdaten zur Überprüfung, ob der Anforderer Ihren bevorzugten Identitätsprovider durchlaufen und erfolgreich authentifiziert hat. Der Identitätsprovider stellt eine erfolgreiche Authentifizierung dar, indem ein Token ausgegeben wird. Bevor Sie die Informationen verwenden oder sich darauf als Assertion verlassen können, die der Benutzer authentifiziert hat, müssen Sie sie validieren.

OpenID Discovery-Dokument

Das OpenID Connect 1.0-Protokoll ist eine einfache Identitätsschicht über dem OAuth 2.0-Protokoll, für die mehrere Endpunkte zur Authentifizierung von Benutzern und zum Anfordern von Ressourcen erforderlich sind, die Benutzerinformationen, Token und PublicKeys enthalten. Um herauszufinden, welche Endpunkte Sie verwenden müssen, können Sie mit OpenID Connect ein Discovery-Dokument verwenden, das ein JSON-Dokument an einem bekannten Speicherort ist. Dieses Discovery-Dokument enthält Schlüssel/Wert-Paare, die Details zur Konfiguration des OpenID Connect-Providers bereitstellen, einschließlich der URIs der Autorisierungs-, Token-, Benutzerinfo- und Public-Keysendpunkte. Sie können das Discovery-Dokument für den OpenID Connect-Service einer IAM-Identitätsdomain abrufen unter: https://<domainURL>/.well-known/openid-configuration.

Weitere Informationen finden Sie in der Discovery-Dokumentation zu Oracle Identity Cloud Service OpenID.

Identitätstoken validieren

Ein Identity-(ID-)Token ist ein integritätsgesichertes, in sich geschlossenes Token (im JSON Web Token-Format), das Claims zum Endbenutzer enthält. Es stellt die Session eines authentifizierten Benutzers dar. Daher muss das Token validiert werden, bevor eine Anwendung dem Inhalt des ID-Tokens vertrauen kann. Beispiel: Wenn ein böswilliger Angreifer das ID-Token eines Benutzers wiedergab, das er zuvor erfasst hatte, sollte die Anwendung erkennen, dass das Token wiedergegeben wurde oder verwendet wurde, nachdem es abgelaufen war, und die Authentifizierung verweigern.

Das ID-Token wird im OpenID Connect-Standard definiert und ist die primäre Erweiterung, die OpenID Connect für OAuth 2.0 ausführt, um die Authentifizierung zu aktivieren. ID-Token sind sensibel und können beim Abfangen missbraucht werden. Stellen Sie sicher, dass diese Token sicher behandelt werden, indem Sie sie nur über HTTPS und nur mit POST-Daten oder innerhalb von Anforderungsheadern senden. Wenn Sie sie auf Ihrem Server speichern, müssen Sie sie auch sicher speichern.
  1. Stellen Sie sicher, dass der Wert des Zielgruppenanspruchs (aud) den Wert client_id der Anwendung enthält. Der Claim aud (Zielgruppe) kann ein Array mit mehreren Elementen enthalten. Das ID-Token muss abgelehnt werden, wenn das ID-Token den Client nicht als gültige Zielgruppe auflistet oder zusätzliche Zielgruppen enthält, die vom Client nicht vertrauenswürdig sind.

  2. Prüfen Sie, ob die aktuelle Zeit vor der Zeit liegt, die durch den Ablaufzeitanspruch (exp) dargestellt wird.

  3. Überprüfen Sie, ob das ID-Token ordnungsgemäß vom Aussteller signiert wurde. Von der IAM-Identitätsdomain ausgegebene Token werden mit einem der Zertifikate signiert, die sich in der URI befinden, die im Feld jwks_uri des Discovery-Dokuments angegeben ist.
    • Rufen Sie das öffentliche Zertifikat des Mandanten vom SigningCert/jwk-Endpunkt ab (Beispiel: https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk).

      Hinweis

      Da Identitätsdomains PublicKeys selten ändern, können Sie die PublicKeys cachen und in den meisten Fällen die lokale Validierung effizient ausführen. Dazu müssen Zertifikate abgerufen und geparst und die entsprechenden Kryptoaufrufe getätigt werden, um die Signatur zu prüfen:
    • Verwenden Sie beliebige verfügbare JWT-Librarys, um beispielsweise die Nimbus JWT Library von Connect2id für Java zu validieren. Eine Liste der verfügbaren Librarys finden Sie unter JWT.

      Hinweis

      Im Falle eines Fehlers bei der Signaturvalidierung sollte das erneute Abrufen/Erneut Zwischenspeichern des Public Keys auf einem Zeitintervall (z. B. 60 Minuten) basieren, um bei Angriffen mit gefälschten Token konstante Wiedereinstellungen zu verhindern, sodass Wiedereinstellungen nur alle 60 Minuten erfolgen.

    Beispiel

    package sample;
     
    import java.net.MalformedURLException;
    import java.net.URL;
     
    import com.nimbusds.jose.JWSAlgorithm;
    import com.nimbusds.jose.jwk.source.JWKSource;
    import com.nimbusds.jose.jwk.source.RemoteJWKSet;
    import com.nimbusds.jose.proc.JWSKeySelector;
    import com.nimbusds.jose.proc.JWSVerificationKeySelector;
    import com.nimbusds.jose.proc.SecurityContext;
    import com.nimbusds.jwt.JWTClaimsSet;
    import com.nimbusds.jwt.proc.ConfigurableJWTProcessor;
    import com.nimbusds.jwt.proc.DefaultJWTProcessor;
     
    public class TokenValidation {
     
        public static void main(String[] args) {
            try {
                String tokenValue = "eyJ4NXQjUzI1....W9J4oQ";
         
                ConfigurableJWTProcessor jwtProcessor = new DefaultJWTProcessor();
     
                // change t
                JWKSource keySource = new RemoteJWKSet(new URL("https://<domainURL>/admin/v1/SigningCert/jwk"));
     
                // The expected JWS algorithm of the token (agreed out-of-band)
                JWSAlgorithm expectedJWSAlg = JWSAlgorithm.RS256;
     
                // Configure the JWT processor with a key selector to feed matching public
                // RSA keys sourced from the JWK set URL
                JWSKeySelector keySelector = new JWSVerificationKeySelector(expectedJWSAlg, keySource);
                jwtProcessor.setJWSKeySelector(keySelector);
     
                // Process the token
                SecurityContext ctx = null; // optional context parameter, not required here
                JWTClaimsSet claimsSet = jwtProcessor.process(tokenValue, ctx);
                // Print out the token claims set
                System.out.println(claimsSet.toJSONObject());
                 
     
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
     
    }
  4. Prüfen Sie, ob der Wert des Issuer Identifier-(iss-)Claims genau mit dem Wert des iss-(Emittenten-)Claims übereinstimmt: https://<domainURL>/

Zugriffstoken validieren

Für erfolgreiche OAuth-Transaktionen muss der Autorisierungsserver der Identitätsdomain OAuth Zugriffstoken ausgeben, die zur Authentifizierung eines API-Aufrufs verwendet werden können. Ein Zugriffstoken stellt eine Autorisierung dar, die an die Clientanwendung ausgegeben wird und Zugangsdaten für den Zugriff auf geschützte OAuth-Ressourcen enthält. Um ein Zugriffstoken zu validieren, das vom Autorisierungsendpunkt ausgegeben wird, muss der Anwendungsclient Folgendes ausführen:
Hinweis

Siehe Tabelle Zugriffstoken.
  1. Überprüfen Sie, ob das Zugriffstoken ordnungsgemäß vom Aussteller signiert wurde.

    • Rufen Sie das öffentliche Zertifikat des Mandanten vom SigningCert/jwk-Endpunkt ab (Beispiel: https://acme.identity.oraclecloud.com/admin/v1/SigningCert/jwk).

      Hinweis

      Da Identitätsdomains PublicKeys selten ändern, können Sie die PublicKeys cachen und in den meisten Fällen die lokale Validierung effizient ausführen. Dazu müssen Zertifikate abgerufen und geparst und die entsprechenden Kryptoaufrufe getätigt werden, um die Signatur zu prüfen:
    • Verwenden Sie beliebige verfügbare JWT-Librarys, um beispielsweise die Nimbus JWT Library von Connect2id für Java zu validieren. Eine Liste der verfügbaren Librarys finden Sie unter JWT.

    • Übergeben Sie das Zertifikat beispielsweise mit der Nimbus SignedJWT-API an die API der jeweiligen Bibliothek:

      PublicKey = x509Certificate.getPublicKey();
      // verify the signature.
      JWSVerifier verifier = new RSASSAVerifier((RSAPublicKey) (publicKey));
      boolean isTokenValid = signedJWT.verify(verifier);
      
      Hinweis

      Im Falle eines Fehlers bei der Signaturvalidierung sollte das erneute Abrufen/Erneut Zwischenspeichern des Public Keys auf einem Zeitintervall (z. B. 60 Minuten) basieren, um bei Angriffen mit gefälschten Token konstante Wiedereinstellungen zu verhindern, sodass Wiedereinstellungen nur alle 60 Minuten erfolgen.
  2. Prüfen Sie, ob der Wert des Issuer Identifier-(iss-)Claims genau mit dem Wert des iss-(Emittenten-)Claims übereinstimmt: https://<domainURL>/

  3. Prüfen Sie, ob das Zugriffstoken den vom Client angeforderten Zielgruppenanspruch (aud) aufweist. Der Wert des Anspruchs aud ändert sich von Geltungsbereich zu Geltungsbereich. Der aud-Anspruch ist ein Array, wenn mehrere Zielgruppen vorhanden sind. Er ist eine Zeichenfolge, wenn nur eine Zielgruppe vorhanden ist.

    Der aud-Claim ist die primäre Zielgruppe des Ressourcenservers der IAM-Identitätsdomainanwendung. Wenn sekundäre Zielgruppen in der IAM-Identitätsdomainanwendung definiert sind, werden sie auch als Teil des aud-Claims hinzugefügt. Im Rahmen der Validierung des Zugriffstokens muss der Server den Zugriff zulassen, wenn einer der Werte im Array aud für den Ressourcenserver sinnvoll ist.

  4. Prüfen Sie, ob die aktuelle Zeit vor der Zeit liegt, die durch den Ablaufzeitanspruch (exp) dargestellt wird.

  5. Prüfen Sie, ob das Zugriffstoken berechtigt ist, den Vorgang basierend auf dem Inhalt des Geltungsbereichsanspruchs auszuführen. Der Scope Claim im Zugriffstoken ist eine durch Leerzeichen getrennte Liste von Zeichenfolgen.