it-swarm.com.de

Wie wird eine rollenbasierte Autorisierung mit OAuth2 / OpenID Connect durchgeführt?

Ich versuche, OAuth2 für die Authentifizierung/Autorisierung zu verwenden, aber nach langem Lesen bin ich verwirrt ... Ich versuche zu verstehen, wie OAuth und OpenIDConnect zueinander in Beziehung stehen und wie genau ich kann sie für die Autorisierung verwenden.

Nach dem, was ich bisher verstanden habe :

  • OpenID Connect eignet sich am besten für die Authentifizierung, OAuth eignet sich am besten für die Autorisierung
  • OAuth2 Die Autorisierung erfolgt über Bereiche
  • Ein Bereich ist die Berechtigung, die der Benutzer einem Client erteilt und die auf dem Ressourcenserver überprüft wurde

  • ein OpenID Connect-ID_Token ist hauptsächlich für die Clientanwendung gedacht, um Benutzerinformationen bereitzustellen, und NICHT als Möglichkeit für den Ressourcenserver, den Benutzer zu validieren

Hier ist mein Anwendungsfall :

  • Ich muss SSO für eine Reihe von vollständig zustandslosen Webservices bereitstellen, die von uns erstellt wurden
  • OAuth ist auf die Gewährung von resource_owner beschränkt
  • Der Identitätsserver wird auf unserer Seite bereitgestellt und mit einem LDAP-Server verbunden
  • Nur vertrauenswürdige Apps können als Dienstanbieter registriert werden

Und was ich versuche zu tun, was mich verwirrt :

  • Nur autorisiert Benutzer können auf eine bestimmte Webservice-API zugreifen

Ich brauche also eine Möglichkeit, die Berechtigung zu überprüfen, die eine externe Entität einem Benutzer auf dem Ressourcenserver erteilt. Was, glaube ich, die Verwendung von OAuth für die Autorisierung) ausschließt?

Ich bin mir nicht sicher, wie ich dies mit OAuth/OpenID connect erreichen soll oder ob es zu meinem Anwendungsfall passt.

  1. Kann ein rollenbasierter Zugriff überhaupt für OAuth2-Bereiche durchgeführt werden?
  2. Wäre es in Ordnung, das id_token mit einem Anspruch, der die Rollen des Benutzers enthält, an den Ressourcenserver zu übergeben (und das access_token insgesamt zu verwerfen)? Das id_token wird also sowohl für die Authentifizierung als auch für die Autorisierung verwendet. Angesichts der Tatsache, dass das id_token signiert ist und Hashes enthält, wäre es in Ordnung, oder?
  3. Sollte ich mich nur bei OpenIDConnect authentifizieren, indem ich das Vorhandensein des id_token überprüfe, das access_token komplett verschrotte und mein eigenes rollenbasiertes Autorisierungssystem entwickle?

Entschuldigung für die Textwand, ich bin mir nur nicht sicher, ob ich den Umfang von OAuth/OpenID Connect hier falsch verstehe. Mache ich die falschen Annahmen?

Vielen Dank.

19
lv.

Das Rollenkonzept kann mit Zugriffstoken in OpenID Connect (Oauth2) verwendet werden.

Beachten Sie, dass ein Bereich eine Anforderung für Ansprüche über den Benutzer ist, die im Zugriffstoken enthalten sein sollen. Die API, die den Zugriff anfordert, weiß, dass sie die Rolle "Mitarbeiter" benötigt, einschließlich "scope=openid roles "Abfrageparameter in der Anfrage.

Der Authentifizierungsserver (AS) hat Zugriff auf Rolleninformationen über den Benutzer (z. B. in einem LDAP-Verzeichnis). Es kann dann die Rollen des Benutzers nachschlagen und sie in den Anspruch "Rollen" im Zugriffstoken aufnehmen.

Sie können den Bereich auch eingrenzen, indem Sie die Rolle selbst anfordern (scope=openid employee), in welchem ​​Fall der AS es einschließen könnte, wenn der Benutzer Mitglied dieser Gruppe ist. Dies ist etwas weniger skalierbar, da es detaillierte Kenntnisse über die erforderlichen Rollen erfordert, aber die Menge an PII im Token und seine Größe verringert. Wenn der Benutzer kein Mitglied der angegebenen Gruppe ist (dh der Bereich kann nicht in das Token aufgenommen werden), muss der AS die API gemäß OAuth2 darüber informieren.

Die Verwendung von Rollen ist ziemlich häufig, und einige Beispiele finden Sie unter:

Also zu den Fragen 2) und 3): Tu das nicht :)

4
Geir Emblemsvag