Tokenvalidierung

Warum validieren wir Token? Wenn Ihre Webanwendung die Zugangsdaten direkt prüft, prüft sie, ob der Benutzername und das Kennwort dem von Ihnen verwalteten entsprechen. Wenn Sie eine anspruchsbasierte Identität verwenden, geben Sie diese Stelle an einen Identitätsanbieter aus.

Die Zuständigkeit wechselt von der Prüfung von Raw-Zugangsdaten zur Prüfung, ob der Anforderer Ihren bevorzugten Identitätsprovider durchlaufen und erfolgreich authentifiziert hat. Der Identitätsprovider stellt eine erfolgreiche Authentifizierung durch Ausgabe eines Tokens dar. Bevor Sie die Informationen verwenden oder sich darauf verlassen können, dass der Benutzer authentifiziert hat, müssen Sie sie validieren.

OpenID Discovery-Dokument

Das OpenID Connect 1.0-Protokoll ist ein einfacher Identitätslayer über dem OAuth 2.0-Protokoll, der die Verwendung mehrerer Endpunkte zur Authentifizierung von Benutzern und zum Anfordern von Ressourcen erfordert, die Benutzerinformationen, Token und Public Keys enthalten. Um zu ermitteln, welche Endpunkte Sie verwenden müssen, können Sie mit OpenID Connect ein Discovery-Dokument verwenden, bei dem es sich um ein JSON-Dokument handelt, das an einem bekannten Speicherort gefunden wird. Dieses Discovery-Dokument enthält Schlüssel/Wert-Paare, die Details zur Konfiguration des OpenID Connect-Providers enthalten, einschließlich der URIs der Autorisierungs-, Token-, Benutzerinfo- und PublicKey-Endpunkte. Sie können das Discovery-Dokument für den OpenID Connect-Service einer IAM-Identitätsdomain von folgender Website abrufen: https://<domainURL>/.well-known/openid-configuration.

Weitere Informationen finden Sie in den Discovery-Dokumenten zu Oracle Identity Cloud Service OpenID.

Identitätstoken validieren

Ein Identitäts-(ID-)Token ist ein integritätsgesichertes, eigenständiges Token (im JSON Web Token-Format), das Ansprüche über den 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 ablehnen.

Das ID-Token wird im OpenID Connect-Standard definiert und ist die primäre Erweiterung, die OpenID Connect an OAuth 2.0 vornimmt, um die Authentifizierung zu aktivieren. ID-Token sind sensibel und können missbraucht werden, wenn sie abgefangen werden. Stellen Sie sicher, dass diese Token sicher verarbeitet werden, indem Sie sie nur über HTTPS und nur mithilfe von POST-Daten oder innerhalb von Anforderungsheadern senden. Wenn Sie sie auf Ihrem Server speichern, müssen Sie sie auch sicher aufbewahren.
  1. Stellen Sie sicher, dass der Wert des Zielgruppenanspruchs (aud) den Wert client_id der Anwendung enthält. Der Claim aud (audience) 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 wenn es zusätzliche Zielgruppen enthält, denen der Client nicht vertraut.

  2. Stellen Sie sicher, dass die aktuelle Zeit vor der Zeit liegt, die durch den Claim für die Ablaufzeit (exp) dargestellt wird.

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

      Hinweis

      Da Identitätsdomains Public Keys selten ändern, können Sie die Public Keys cachen und in den meisten Fällen eine lokale Validierung effizient durchführen. Dazu müssen Zertifikate abgerufen und geparst und die entsprechenden Kryptoaufrufe ausgeführt werden, um die Signatur zu prüfen:
    • Verwenden Sie alle verfügbaren JWT-Librarys, um beispielsweise die Nimbus JWT Library for Java von Connect2id zu validieren. Eine Liste der verfügbaren Librarys finden Sie unter JWT.

      Hinweis

      Im Falle eines Fehlers bei der Signaturvalidierung sollte das erneute Abrufen/erneute Caching des Public Keys auf einem Zeitintervall basieren, wie z.B. 60 Minuten, damit Neufestsetzungen nur alle 60 Minuten erfolgen, um ständige Neufestsetzungen bei Angriffen mit falschen Token zu verhindern.

    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. Stellen Sie sicher, dass der Wert des Claims der Aussteller-ID (iss) genau mit dem Wert des Claims iss (Aussteller) übereinstimmt: https://<domainURL>/

Zugriffstoken validieren

Erfolgreiche OAuth-Transaktionen erfordern, dass der Autorisierungsserver der Identitätsdomain OAuth Zugriffstoken zur Authentifizierung eines API-Aufrufs ausgibt. 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 vom Autorisierungsendpunkt ausgegebenes Zugriffstoken zu validieren, muss der Anwendungsclient die folgenden Schritte ausführen:
Hinweis

Siehe Tabelle Zugriffstoken.
  1. Stellen Sie sicher, dass das Zugriffstoken vom Aussteller ordnungsgemäß signiert wurde.

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

      Hinweis

      Da Identitätsdomains Public Keys selten ändern, können Sie die Public Keys cachen und in den meisten Fällen eine lokale Validierung effizient durchführen. Dazu müssen Zertifikate abgerufen und geparst und die entsprechenden Kryptoaufrufe ausgeführt werden, um die Signatur zu prüfen:
    • Verwenden Sie alle verfügbaren JWT-Librarys, um beispielsweise die Nimbus JWT Library for Java von Connect2id zu validieren. Eine Liste der verfügbaren Librarys finden Sie unter JWT.

    • Übergeben Sie das Zertifikat an die API der jeweiligen Bibliothek, z.B. mit der Nimbus-API SignedJWT:

      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/erneute Caching des Public Keys auf einem Zeitintervall basieren, wie z.B. 60 Minuten, damit Neufestsetzungen nur alle 60 Minuten erfolgen, um ständige Neufestsetzungen bei Angriffen mit falschen Token zu verhindern.
  2. Stellen Sie sicher, dass der Wert des Claims der Aussteller-ID (iss) genau mit dem Wert des Claims iss (Aussteller) übereinstimmt: https://<domainURL>/

  3. Stellen Sie sicher, dass das Zugriffstoken den vom Client angeforderten Zielgruppen-Claim (aud) aufweist. Der Wert des Claims aud ändert sich von Geltungsbereich zu Geltungsbereich. Der Claim aud 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 in der IAM-Identitätsdomain-App sekundäre Zielgruppen definiert sind, werden diese auch als Teil des aud-Claims hinzugefügt. Im Rahmen der Zugriffstokenvalidierung muss der Server den Zugriff zulassen, wenn einer der Werte im Array aud für den Ressourcenserver sinnvoll ist.

  4. Stellen Sie sicher, dass die aktuelle Zeit vor der Zeit liegt, die durch den Claim für die Ablaufzeit (exp) dargestellt wird.

  5. Prüfen Sie, ob das Zugriffstoken zur Ausführung des Vorgangs basierend auf dem Inhalt des Geltungsbereichs-Claims autorisiert ist. Der Geltungsbereich-Claim im Zugriffstoken ist eine durch Leerzeichen getrennte Liste von Zeichenfolgen.