OpenID Hinweise zur Implementierung von Connect

Online bearbeiten

IBM® Verify führt weiterhin Sicherheitsverbesserungen an der Implementierung von „ OpenID Connect“ durch, indem es bewährte Sicherheitsverfahren befolgt. Die Kompatibilität mit früheren Versionen wird so weit wie möglich gewahrt, doch müssen Sie einige Einstellungen ändern, um die Sicherheit zu verbessern.

Änderungen an der Implementierung von „ OpenID Connect“

  • Einige Fehlermeldungen werden möglicherweise aktualisiert, die Meldungs-ID bleibt jedoch unverändert. Wenn Sie einen Prozess haben, der Logik zum Auslesen von Antwortnachrichten enthält, verwenden Sie stattdessen die Nachrichten-ID.
  • Wenn der Autorisierungs-Endpunkt aufgerufen wird, um einen Autorisierungscode oder Tokens abzurufen, wird der Benutzer möglicherweise zur Anmeldung oder zur Multi-Faktor-Authentifizierung weitergeleitet. In einem Browser führt diese Aktion zu einigen automatischen Weiterleitungen. Wenn Ihre Testautomatisierung auf diesem Ablauf basiert, sollten Sie darauf achten, dass auch Weiterleitungen automatisch verfolgt werden.
  • Bei Endpunkten, die einen Bereich zurückgeben, wird die Nicht-Rückgabe von Bereichen oder die Rückgabe einer leeren Zeichenfolge für die Bereiche gleich behandelt.
  • Ein Schrägstrich (/) in einer JSON-Zeichenkette wird möglicherweise nicht maskiert. Stellen Sie sicher, dass Ihr JSON-Parser beide Fälle abdeckt.
  • API-Berechtigungen werden in der Einwilligungsaufforderung für den Benutzer nicht mehr angezeigt. Den für diesen Kunden generierten Tokens werden weiterhin API-Berechtigungen gewährt.
  • Die Spezifikation erlaubt die Verwendung des http Schemas in der redirect_uri nur, wenn das hostname entweder oder die IP-Loopback-Literale ist localhost . Siehe OpenID, Abschnitt „Connect Core“ 1.0:, 3.1.2.1. Authentifizierungsanfrage.
  • Es ist nicht immer davon auszugehen, dass Abfrageparameter in derselben Reihenfolge stehen. Verwenden Sie bei der Verarbeitung von Abfrageparametern die entsprechende Bibliothek oder sorgen Sie für eine robuste regex Lösung, die den Parameter unabhängig von der Reihenfolge findet.

Zukünftige Änderungen an der Implementierung von „ OpenID Connect“

Bei den folgenden Punkten müssen Sie vorerst keine Änderungen vornehmen. Es wird jedoch dringend empfohlen, diese Einstellungen anzupassen, um sicherzustellen, dass Ihre Implementierung von „ OpenID Connect“ den Best Practices entspricht und für künftige Änderungen gerüstet ist.
  • Im Allgemeinen ist es sicherer, wenn die Parameter bei POST-Anfragen im Anfragetext statt in den Abfrageparametern enthalten sind.
  • Der nonce Parameter muss ein kryptografisch zufälliger Wert sein, damit er für Angreifer nicht erraten werden kann. Achte darauf, dass es lang genug und zufällig ist. Siehe Hinweise zur Nonce-Implementierung. Es werden mindestens 8 Zeichen empfohlen.
  • Der Autorisierungsserver (IBM Verify) generiert einen Autorisierungscode und Token beliebiger Länge, was sich aus Sicherheitsgründen in Zukunft ändern könnte. Wenn die Tokens gespeichert werden, sollten mindestens 1024 Zeichen für die Token-Länge vorgesehen werden. Die Länge von Tokens im JWT-Format, wie beispielsweise des ID-Tokens oder des Zugriffstokens im JWT-Format, hängt vom Inhalt des JWTs ab. Der Inhalt des JWT wird erweitert, wenn ihm weitere Attribute zugeordnet werden.
  • Bei Token vom Typ „Bearer“ wird die Groß-/Kleinschreibung nicht berücksichtigt, beispielsweise „Bearer“ oder „bearer“. Verwenden Sie bei der Überprüfung dieses Werts keine Groß-/Kleinschreibung.
  • Wenn der Refresh-Token-Ablauf durchgeführt wird, enthalten neue ID-Token nicht mehr den ursprünglichen Nonce-Wert. Der nonce vom ursprünglichen Ablauf zurückgegebene Wert dient dazu, Replay-Angriffe auf Autorisierungsanfragen abzuwehren; diese Schutzmaßnahme ist für nachfolgende Token-Anfragen im Rahmen des Refresh-Token-Ablaufs nicht erforderlich.
  • Ähnlich wie noncebei muss der PKCE-Code-Verifizierer ein kryptografisch zufälliger Wert sein, der nicht erraten werden kann. Gemäß den Spezifikationen muss der Code-Prüfcode mindestens 43 Zeichen lang sein. Siehe RFC 7636.
  • Verwenden Sie den state Parameter, um Cross-Site-Request-Forgery zu verhindern, indem Sie einen nicht erratbaren Wert festlegen, der überprüft werden kann. Erstellen Sie beispielsweise einen Hash des Sitzungs-Cookies, das zur Authentifizierung des User-Agents verwendet wird. Siehe RFC 6749. Es werden mindestens 8 Zeichen empfohlen.
  • Der Wert für aud „audience“ kann eine Zeichenkette oder ein Array sein. Insbesondere wenn nur ein Wert für die Zielgruppe vorhanden ist, kann es sich um eine Zeichenkette oder ein Array mit einer Zeichenkette handeln.
  • Der Zugriffstyp „Client-Credential Grant“ dient dazu, Zugriffstoken für den maschinenübergreifenden Zugriff zu generieren. Gehen Sie nicht davon aus, dass diese Art der Autorisierung ein ID-Token generieren kann oder dass das Zugriffstoken für den Zugriff auf den userinfo Endpunkt verwendet werden kann.
  • Der typ Header-Parameter „(type)“ im ID-Token ist optional. Die vertrauende Partei darf keinen Header-Parameter typ im ID-Token erwarten.