oAuth2 und ClientCredentials für API sinnvoll?

[Thallius]

Hallo,

Ich arbeite schon länger mit oAuth2 und finde es auch im Prinzip eine gute Sache, wenn man es erstmal kapiert hat. Allerdings hatte ich bisher immer den Fall, dass ich den Token also AuthorizationCode angefordert habe, was ja mit callbacks etc. funktioniert und dadurch eine starke Absicherung erzeugt wird.

Jetzt habe ich das erste mal, dass ich den Token für eine API anfordere als ClientCredential. Hier frage ich mich echt, wo da der Sinn liegt. Ich mache ja nichts anderes als einen Request mit BasicAuth an den Auth Server und bekomme einen Auth Token zurück. Mit diesem Token kann ich dann die API ansprechen.

Da kann man aber doch auch gleich die API mit einem Login versehen und einer SessionId arbeiten.

Wo liegt denn hier der Vorteil des oAuth?

Gruß

Claus

 

[httpdigest]

Zwei Worte: "Single Responsibility" und "Single Sign-On".
Wenn dein Service-Netzwerk sagen wir mal aus 20 Services besteht, die per API Gateway von einem Client angesprochen werden, dann möchtest du doch nicht den Client/Browser/User 20 Mal auffordern, für jeden einzelnen Service sich mit irgendwelchen Credentials (Benutzername/Passwort) anzumelden und jeder Service sich diese Authentisierungs-Information in irgendeinem eigenen SessionToken/Cookie/Header/Payload oder sonstwas merkt, die dann vom API Gateway irgendwie orchestriert werden müssen. Der Benutzer soll sich bitte nur ein einziges Mal anmelden und die Information, dass er angemeldet/authentisiert ist, soll nur ein einziges Mal vorliegen und in einer Form, die für alle Services dieselbe ist (also etwa als JWT Token). Dieser Token soll dann auch bitte nur von einem einzelnen Authentication Provider erzeugt werden (etwa per LDAP gegen ein ActiveDirectory oder sonstigen Identity Provider). Du möchtest hier auch nicht, dass jeder der 20 Services als LDAP Client agiert und die einzelnen Services bei einem Authentication/Identity Provider anfragen, ob der Benutzer der ist, für den er sich (per Credentials, Username/Passwort, irgendwas) ausgibt. Das sieht man in so vielen Unternehmensarchitekturen. Jede Anwendung ist quasi ein eigener LDAP Client und dieses Pattern erlaubt absolut keine Orchestrierung der Services (wenn man etwa in Richtung Microservices-Architektur gehen will).
Es gibt noch viele andere Vorteile, wie etwa, dass der OAuth2 Token mit einer kontrollierbaren Ablaufzeit versehen werden kann, was für ein Username/Passwort eventuell schwerer zu realisieren ist. OAuth2 entkoppelt also die Information, dass ein Benutzer authentisiert ist von der Information, wie sich ein Benutzer denn authentisieren kann.

 

[Thallius]

Naja,

Der erste Punkt stimmt in dem Fall wo die Services durch den gleichen Dienst gehen. Wenn aber die Webservices alle von anderen Anbietern kommen hast damit nichts gewonnen.

Eine sessionId hat auch eine definierte Ablaufzeit. Das ist jetzt keine Neuerung eines Tokens.

Gruß

Claus

 

[httpdigest]

Eine sessionId bekommst du aber erst dann, wenn du dich - wie gesagt - bei einem Service erstmal authentisierst. Das möchte man aber im optimalen Fall nicht, sondern sich nur _einmal_ gegen einen Identity Provider authentisieren und dieser stellt einem ein Token aus, welches die Authentizität desjenigen, der den Token besitzt, beweist. Natürlich müssen da aber alle Services dann auch mitspielen, also OAuth2-fähig sein. Wenn dein Service, der mit sessionIds arbeitet, das nicht ist, dann geht da OAuth2 natürlich nicht.