Laden...

Oauth 2.0 Grundlagen zur Authorisierung

Erstellt von brave_snoopy vor 2 Jahren Letzter Beitrag vor 2 Jahren 577 Views
B
brave_snoopy Themenstarter:in
99 Beiträge seit 2011
vor 2 Jahren
Oauth 2.0 Grundlagen zur Authorisierung

Hallo,

ich bin auf der Suche zum Verständnis von oauth. Grundsätzlich möchten wir einen zentralen Identity Provider haben, an dem verschiedene Webportale und API angedockt werden, so dass zwischen den Portalen und Apis Sso möglich ist.
Als idp denken wir derzeit an azure b2c.

Wir können bereits die Portale mittels oauth anbinden. Die Testbenutzer können alles nutzen.

Die Frage ist, wie und wo steuert man mit oauth ob ein User ein bestimmtes Web Portal nutzen darf, oder nicht. Wenn ich es richtig bis jetzt verstehe, prüft das Webportal nur, ob das jwt Token gültig ist. Aber wenn der idp ein Token erstellt, ist dieses ja grundsätzlich für alle registrierten Anwendungen gültig.

Leider finde ich im Netz überhaupt nichts zu dem Thema.

16.807 Beiträge seit 2008
vor 2 Jahren

Die Frage ist, wie und wo steuert man mit oauth ob ein User ein bestimmtes Web Portal nutzen darf, oder nicht. Ressourcenbasierte Autorisierung in ASP.net Core

Leider finde ich im Netz überhaupt nichts zu dem Thema.

Na, glaub ich jetzt nicht so ganz 😉 OAuth und Co ist extrem gut dokumentiert.

OpenId -> Authentication: wer ist jemand
OAuth -> Authorization: was darf jemand grundlegend

Authorisierungen gegen spezifische Ressourcen werden in keinen der beiden Token abgelegt sondern live geprüft.
Sowas nennt sich übergreifend Policy-based Authorization (die .NET Implementierung nennt sich eben Resource-based Authorization, die dann über Policies läuft) und ist eigentlich zumindest im Schema in jeder OAuth-Doku enthalten; sogar in den RFCs als Empfehlung - und zwar beim Hinweis, dass Du den Token nicht mit irgendwelche Rechteverwaltungen zuballern sollst, weil sonst der Token zu groß wird.

B
brave_snoopy Themenstarter:in
99 Beiträge seit 2011
vor 2 Jahren

Danke für deine Antwort. Ja oauth selbst ist gut dokumentiert. Mir fehlt aber leider immer noch der Zusammenhang.

Es gibt ja zum Beispiel die Scopes. Diese können dafür nicht genutzt werden, oder?
Hast du Erfahrung mit azure b2c?

16.807 Beiträge seit 2008
vor 2 Jahren

Nein, Scopes sind nicht für Dritt-Ressourcen-Berechtigungen gedacht; wird aber gern von entweder faulen oder unwissenden Entwicklern dafür verwendet, was man dann später sehr aufwendig rausoperieren darf.
Erst jetzt wieder ein Projekt gehabt, in dem ein Entwickler dachte er muss den Token völlig Standard-Fremd missbrauchen, was dazu führt, dass man keinerlei Standard-Bibliotheken verwenden kann und es an zig Stellen Inkompatibilitäten gibt.
Das ist weit weit weg von Security by Design - sollte man nicht tun. OpenId/OAuth bzw. JWT sind sehr erwachsene Protokolle, die man ruhig so verwenden darf, wie sie gedacht sind 🙂

Scopes sind letzten Endes nichts anderes als die Zusammenfassung von Claims; und in einem Claim kann zB. gespeichert werden, ob die Dritt-App (zB. eine API) Zugriff auf die E-Mail, oder den Name etc.. (siehe Open ID default scopes) hat, oder nicht. Also die Zustimmung des Consent.
Ebenso kann man ein Claim dafür verwenden, ob der User zB. Berechtigung auf eine User-API hat (zB. mit typischen Scopes wei "users", "users_read", "users_write").

In einem Claim wird aber niemals der Zugriff auf eine spezifische Ressource (zB. "UserId 123") abgelegt.
Genau dafür gibt es Policies. Das gilt für alle Systeme im OpenId/OAuth Umfeld, egal ob AAD, AWS Incognito, IdentityServer.... siehe dazu https://openid.net/developers/specs/

Hast du Erfahrung mit azure b2c?

Ja.

B
brave_snoopy Themenstarter:in
99 Beiträge seit 2011
vor 2 Jahren

Ist es richtig, dass der Zugriff demnach an der Anwendung bzw. dem Service geprüft wird und nicht beim Erstellen des JWT Token?
siehe: Richtlinien basierte Autorisierung in ASP.net Core

Würde das bedeuten, ich kann im B2C unterhalb von "Roles and Administrators" eine neue Rolle anlegen. Z.B. "Webservice1 lesen", die einem User zuweisen und am Webservice dann prüfen, ob der Benutzer der ankommt, die Rolle "Webservice1 lesen" angehört?

Wenn ich aber in meinem B2C unterhalb von "Roles and Administration" schaue, ist dies wohl nur ein Preview Feature. Ist dies noch nicht überall freigeschaltet? Ich kann demnach keine Custom Role anlegen.

Werden die Rollen automatisch im JWT gespeichert?, oder muss dies noch aktiviert werden beim Azure B2C?

16.807 Beiträge seit 2008
vor 2 Jahren

Ist es richtig, dass der Zugriff demnach an der Anwendung bzw. dem Service geprüft wird und nicht beim Erstellen des JWT Token?

Wenn ich die Frage neutral lesen würde, würde ich denken, dass Du Dir das Thema Token Authentication bislang nicht angeschaut hast 😉

Ein Token stellst Du an Punkt X aus und ist Y Stunden gültig.
Willst Du wirklich bei einem Rechte-Change auf eine Ressource niemals mehr Rechte prüfen, solange der Token gültig ist?
Nein -> Du prüfst Permissions auf Ressourcen immer live, egal was im Token steht; denn im Token steckt keine Ressource Permission.

...
Werden die Rollen automatisch im JWT gespeichert?, oder muss dies noch aktiviert werden beim Azure B2C?

So wie sich das anhört willst Du App Roles haben.

App Roles landen im Token
https://docs.microsoft.com/de-de/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps

App Roles sind aber auch nur "Rollen" und kein Resourced-based Permission System.

B
brave_snoopy Themenstarter:in
99 Beiträge seit 2011
vor 2 Jahren

Das ist genau das Thema, es gibt so unzählige viele Möglichkeiten, und jeder benennt die Themen anders. Zudem scheint es zwischen Azure AD und Azure AD B2C Unterschiede zu geben. Im B2C finde ich derzeit nämlich weder Rollen, noch App Rollen.

Da mir leider auch zusätzlich die ASP.NET Kenntnisse fehlen, wird die Sache nicht unbedingt einfacher.

Ein Token stellst Du an Punkt X aus und ist Y Stunden gültig.
Willst Du wirklich bei einem Rechte-Change auf eine Ressource niemals mehr Rechte prüfen, solange der Token gültig ist?
Nein -> Du prüfst Permissions auf Ressourcen immer live, egal was im Token steht; denn im Token steckt keine Ressource Permission.

Das das Token durch den B2C erstellt und dort vorher geprüft wird, ist mir bewusst. Jedenfalls muss sich der User irgendwie Authentifizieren.
Wenn nun aber der Benutzer einen GET Request gegen Ressource X unternimmt, holt er sich ein Access Token vom B2C. Mit diesem Access Token geht er gegen die Ressource X um seinen Request loszulassen.

Ich würde nun erwarten, dass ich im B2C hinterlegen kann, das User A Ressource X verwenden darf.
Die Ressource X beim Zugriff von User A in das Token schaut, und prüft, jupp, User A darf zugreifen.

Das JWT Token selbst ist ja signiert. Daher, wenn die Signatur gültig ist, kann es auch nicht verändert worden sein.

Wenn du aber sagst, die Ressource X prüft live, ob der Zugriff gültig ist, und nicht nur das Token gültig, dann muss ja die Ressource eine ausgehende Verbindung gegen das Azure AD B2C machen und dort die Prüfung ausführen. Aber gegen was prüft er dann? Also welches Attribut im claim?

16.807 Beiträge seit 2008
vor 2 Jahren

Zudem scheint es zwischen Azure AD und Azure AD B2C Unterschiede zu geben.

Jo, sind zwei völlig verschiedene Produkte; gehören nur zur gleichen Produktfamilie.

Da mir leider auch zusätzlich die ASP.NET Kenntnisse fehlen, wird die Sache nicht unbedingt einfacher.

Kein guter Mix.
Du solltest schon wissen, was Du da tust, und da brauchst Du mindestens die Grundlagen + nen zweites Auge von jemanden, der mehr Erfahrung hat.
Ist Security - damit spielt man nicht 😉

Wenn nun aber der Benutzer einen GET Request gegen Ressource X unternimmt, holt er sich ein Access Token vom B2C.

Ja und nein. Das kommt drauf an.

Der Auth Server erstellt den Identity Token, nachdem die Identität festgestellt wurde.
Mit dem Identity Token holt man sich dann vom Auth Server einen AuthN Token gegen die API / APIs.
Die Grundidee sagt, dass man eigentlich einen AuthN Token pro API hat. Mit gewissen Configs (Multi Audience) kann man auch einen AuthN Token gegen mehrere APIs verwenden.
Verwendet man meist dann, wenn die APIs nur zum eigenen Ökosystem gehören.

Ich würde nun erwarten, dass ich im B2C hinterlegen kann, das User A Ressource X verwenden darf.

Ne, so funktioniert OAuth / OpenId nicht bzw. generell kein Authorisierungssystem.
Die Infrastruktur kennt Deine Ressourcen nicht.

Resource AuthN ist immer (auch bei nicht-Token Systemen) Applikationslogik und muss in 99,999% der Fälle selbst implementiert werden.
Das ist also Aufgabe der AuthN Middleware (also Resource based Policies) Deiner Logik aka API.

Die Infrastruktur kann Dir das nicht abnehmen. Soll sie auch nicht.

B
brave_snoopy Themenstarter:in
99 Beiträge seit 2011
vor 2 Jahren

Kein guter Mix.
Du solltest schon wissen, was Du da tust, und da brauchst Du mindestens die Grundlagen + nen zweites Auge von jemanden, der mehr Erfahrung hat.
Ist Security - damit spielt man nicht 😉

Bin ja dabei, mir die Grundlagen anzueignen. Daher hier der Post. Mir ist eben noch kein Blatt über den Weg gelaufen, welches es von A bis Z erklärt.

Der Auth Server erstellt den Identity Token, nachdem die Identität festgestellt wurde.
Mit dem Identity Token holt man sich dann vom Auth Server einen AuthN Token gegen die API / APIs.
Die Grundidee sagt, dass man eigentlich einen AuthN Token pro API hat. Mit gewissen Configs (Multi Audience) kann man auch einen AuthN Token gegen mehrere APIs verwenden.
Verwendet man meist dann, wenn die APIs nur zum eigenen Ökosystem gehören.

Hätte ich kein Problem mit, aber ich habe in meinem B2C (alles Testkonfigurationen) zwei Apps registriert. (In diesem Fall wäre für mich jede App eine eigene API)
Wenn ich nun Postman starte, muss ich dort auch eine Application ID und ein Secret hinterlegen. Dies habe ich von App1 hinterlegt. Wenn ich mir nun mit Postman ein Access Token hole, kann ich mit diesem Token ohne Probleme auf die App2 zugreifen.
Demnach dürfte das ja nicht funktionieren, der Zugriff müsste blockiert werden, oder?

16.807 Beiträge seit 2008
vor 2 Jahren

Wenn ich mir nun mit Postman ein Access Token hole, kann ich mit diesem Token ohne Probleme auf die App2 zugreifen.

Ist valide, wenn man das so konfiguriert.

Die API validiert die Audience im Token gegen die Audience, die in der API hinterlegt ist. Das macht zB die ASP.NET Auth Middleware völlig automatisch.
In einem Token können mehrer Audiences drin stehen (laut RFC); B2C unterstützt das glaube ich aktuell aber nicht.

Wenn also die API den Token akzeptiert, dann validiert sie entweder die Audience nicht oder die Audience ist im Sinne der Authorisierung korrekt.
Es ist durchaus valide, dass alle APIs die gleiche Audience haben.

Aber das sind nun schon sehr viele Basics muss ich sagen; und das ist wirklich dokumentiert. Die Aussage, dass es nichts gibt, die ist einfach nich wahr 😉 Wenn ich Schulungen dazu halte schaue ich immer wieder nach aktuellen Lektüren und bin die letzten Jahre immer fündig für meine Zuhörer geworden - auch in den Microsoft Docs. Daher bin ich da schon im Bilde, auch wenn viele Dokus - zB die RFCs - halt einfach trocken und sehr sachlich sind. Aber da muss man durch. Bestimmt auch über mehrere Seiten hinweg. Dokumentationen funktionieren einfach nicht so, dass auf einem Papier alle Basics stehen würden.
Microsoft hat fast alle Flow Arten sehr gut dokumentiert (ja, gibt viele); der aktuellste für APIs ist derzeit der Auth Code Flow: Microsoft identity platform and OAuth 2.0 authorization code flow - Microsoft identity platform

Bevor Du also rumwurstelst, les einfach ein bisschen Dokumentation.
OAuth 2.0 and OpenID Connect protocols on the Microsoft identity platform - Microsoft identity platform
Das erleichtert Dir auch die Testumgebung sehr, weil Du erst mal verstehen musst, was wofür zuständig ist.

Aber ja: die B2C Dokumentation selbst ist nicht das gelbe vom Ei. Da wirste viel rumprobieren müssen. Kann Dir an der Stelle nur mitgeben, dass meine Kunden (bis auf 2) auf B2C verzichten, weil es bei B2C schon viele Einschränkungen gibt (zB beim Branding etc)... solltest also evaluieren, ob das für Dein Szenario überhaupt akzeptabel ist.
Da Dich aber nur OpenID / OAuth für den Anfang interessiert, ist das weniger wichtig.