OAuth App->Api->Api Auth

Hallo zusammen,

ich habe eine mit OAuth abgesicherte Api welche von einer App aufgerufen wird.
Der authentifizierte Benutzer hat aber auch noch Rollen für einen weiteren Microservice.

Nun soll bei einem Aufruf des Benutzers die Api die Authentifizierung an den Microservice (weitere Api) weiter geben.
Gibt es dazu einen speziellen Begriff oder hat jemand Beispielcode dafür?

Nicht gewollt ist, dass die Apis über ein client-Secret authentifiziert werden.
Es soll auch an der Api des Microservice der Benutzer der App authentifziert werden.

Ich hoffe man kann verstehen was ich beabsichtige.

Vielen Dank!
Matthias

ich habe eine mit OAuth abgesicherte Api welche von einer App aufgerufen wird.
Der authentifizierte Benutzer hat aber auch noch Rollen für einen weiteren Microservice.

Nicht herauslesbar, ob Deine API mit Deinem Code - oder fremde.

Nun soll bei einem Aufruf des Benutzers die Api die Authentifizierung an den Microservice (weitere Api) weiter geben.

Nennt sich On Behalf Flow.
https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use

Nicht gewollt ist, dass die Apis über ein client-Secret authentifiziert werden.

Wenn eine API sich selbst bekannt machen muss, dann muss das mit einem Client Secret / Certificate Verfahren erfolgen, dann funktionieren Benutzerflows nicht (oder Du bist auf Azure, da gibts dann sowas wie Managed Identities..).
Eine API braucht zwingend eine eigene App Registration, damit der On Behalf Flow funktioniert - denn auch eine API braucht Rechte einen solchen Token für On Behalf überhaupt anfragen zu dürfen.

Hör sich an, dass da das Bewusstsein der Flows noch nicht sitzt.
Das muss aber 100% passen, damit das ein sicheres System wird - vor allem bei Microservices.

Hallo Abt,

ich bin mir tatsächlich bei einer Sache nicht ganz sicher.
Bei allen Beispielen die ich zu on behalf of fand, geht es darum, Daten von einem 3rd Party Service abzuholen.

Ich habe zwei Services und für beide Services hat der Benutzer entsprechende Rechte.
Sprich der Benutzer meldet sich an und im Token stehen die Rechte für beide Services.

Somit könnte doch Service A einfach das Token für die Requests an Service B verwenden?

Entschuldige bitte, dass ich so genau nachfrage, aber es geht ja genau darum es richtig zu machen 😉

PS: Gerade für diese Fälle bau ich es ja in der Dev Umgebung und nicht produktiv 🙂

Viele Grüße

Bei allen Beispielen die ich zu on behalf of fand, geht es darum, Daten von einem 3rd Party Service abzuholen.

Bei On Behalf geht es um jede Art von Aktion, die im Namen des Benutzers erfolgen soll.
Die Auth-Architektur entscheidet, wie das aber genau abläuft.

Somit könnte doch Service A einfach das Token für die Requests an Service B verwenden?

Das kommt drauf an.

Generell ist die Idee von einer "verteilten" Microservice-Landschaft, dass ein Token immer nur gegenüber einem Microservice gültig ist.
Die Authorisierung findet also gegen einen einzigen Service statt.

Wenn Du aber eine Plattform baust, und es quasi einen einzigen Gateway gibt und man gar nicht weiß, welche Microservices sich im Hintergrund befinden, dann hat man einen einzigen Token der eben gegen diese "Plattform" gültig ist.

Beispiel:
Dein Token ist für Google Mail Services gültig. Das ist eine Plattform mit mehreren Services.
Der gleiche Token ist aber nicht für Google Maps gültig.

Mein Alltag:
Ich baue fast ausschließlich größere Cloud-Plattformen auf Basis von Microservices.
Die Teams selbst sind jeweils für einen Service verantwortlich.

Der Service ist aber eben von Außen nicht ersichtlich, sondern von aussen sieht man nur api.domain.tld
Es gibt einen einzigen Token, der dann für alle Services gültig ist.
Beim Erstellen des Tokens wird rein geschrieben, welche Scopes hat (zB user:write user:read order:cancel) etc etc.
Service A kann (nicht muss) dann den Token einfach nehmen um andere Aktionen ausführen gegen andere, interne Services.
Aber auch hier kann man On Behalf verwenden, um eine spezifische Authorisierung zu erzwingen (zB höherwertige Rechte etc).

Für andere Plattformen muss es aber super modular sein, dann muss pro Endpunkt ein eigener Token erstellt werden.
zB api-order.domain.tld, api-users.domain.tld
Service A muss nun On Behalf nehmen, weil der Token ja nur für Service A gültig ist, aber nicht für Service B.

Entschuldige bitte, dass ich so genau nachfrage, aber es geht ja genau darum es richtig zu machen 😉

Kein Grund der Entschuldigung, wir haben alle unwissend begonnen.
Man kann das aber in so nem Forenbeitrag kaum alles zusammen fassen, weshalb sich bei solchen Themen wirklich Zeit und Lektüre eignet (oder auch Trainer:in/Berater:in).

Hallo Abt,

vielen Dank für die super Ausführung mit Praxisbezug.
Dies hilft mir extrem weiter.

Oftmals ist ein Praxisbeispiel einfach viel besser als die Theorie in der Literatur / Dokumentation.
(Wobei mir natürlich klar ist, wie unabdingbar und essenziell dies ist)

Gibt leider Themen, da wirst Du allein mit der Praxis nicht schlau draus oder Du machst Fehler, weil Du Auswirkungen nicht kennst.
Sicherheit / Authentifizierung ist nun mal ein Thema, bei dem es auch viel um technische Verständnis und Konzepte geht - das lernt man nicht bei Error.
Und Try and Error bei sicherheitsrelevanten Dingen ist keine gute Idee. Lass das sein.