JWT - Autorisierung & Authentisierung

Meeresgott

Bekanntes Mitglied
Hallo liebes Forum,

aktuell arbeite ich an "einem" Backend, dass aus mehreren Microservices besteht und via Proxy zu einem einzigen Backend für das Frontend zusammen gefügt wird.

Die Authentifizierung übernimmt ein Service und ich arbeite mit JWT um den User für die anderen Services zu identifizieren.

Allerdings bekommt mein Autorisierung-Service zu viel Traffic ab, da nun jeder Service diesen Aufruft und fragt ob der User überhaupt das Recht hat, auf diesen zuzugreifen.

Da ich den JWT bei jedem Aufruf eines Services mit übergebe wäre es sehr bequem einfach in den Body die Rollen des Users bzw gleich die Aufgeschlüsselen Rechte mit zu übergeben.

Wäre das eine schlechte Umsetzung ? Wie habt ihr das Problem gelöst - vielleicht ein zweiter Autorisierungstoken ?

Viele Grüße
 

mrBrown

Super-Moderator
Mitarbeiter
Üblich ist es durchaus, alle nötigen Informationen direkt im Token zu sichern - das ist ja auch grad der Vorteil mit JWT.

Zwei Token einzusetzen ist auch üblich, einen "Refresh"- und einen "Access"-Token. Letzterer wird benutzt, um die einzelnen Services anzusprechen, hat aber nur eine begrenzte Gültigkeitsdauer. Ersterer wird deshalb benutzt, um beim Auth-Service regelmäßig einen neuen Access-Token zu bekommen. Nötige Informationen werden nur im Access-Token benötigt.

OAuth ist vielleicht einen Blick für dich wert.
 

Meeresgott

Bekanntes Mitglied
Hallo MrBrown! Vielen Dank für deine Antwort.

0Auth scheint wirklich alles mit zu bringen, was ich benötige. Ich hoffe nur, dass ich meinen Code flexibel genug geschrieben habe um die vorhandene Authentifizierung / Autorisierung einfach zu ersetzten. Aber das wird sich zeigen ;)

0Auth scheint auch einen Refresh und einen Accesstoken zu verwenden. Kannst du mir vielleicht etwas Lektüre empfehlen warum es so gehandhabt wird ? Müsste nicht jeder "Angreifer" der an ein Refreshtoken von einem Admin kommt das goldene Los gezogen haben ? Oder übersehe ich was ?
 

mrBrown

Super-Moderator
Mitarbeiter
Müsste nicht jeder "Angreifer" der an ein Refreshtoken von einem Admin kommt das goldene Los gezogen haben ? Oder übersehe ich was ?
Denk dir den Fall einmal ohne Refresh-Token: Der Angreifer braucht nur irgendeinen Request abfangen, und hat damit den Access-Token, den er ewig für alles nutzen kann - womit er also für immer das große Los gezogen hat, ohne dass es irgendeine Chance gäbe, ihm das Los wieder zu entziehen.
Oder auch ohne Angreifer: ein Nutzer ist einmal eingeloggt, hat damit einen Access-Token, und behält dann diese Rechte für immer, auch wenn der Nutzer zwischendurch gelöscht wird.


Das ganze mit Refresh-Token: Wenn der Angreifer an den Refresh-Token kommt, kann er sich mit diesem immer neue Access-Token besorgen. Ein andere Admin könnte aber jetzt diesen Account im Auth-Service sperren, dann bringt dem Angreifer der Refresh-Token nichts mehr. Bekommt der Angreifer nur einen Access-Token, kann er damit nur begrenzte Zeit was anfangen, danach ist er ungültig.
Und zum gelöschten Nutzer: Wenn der Nutzer im Auth-Service gelöscht wird, kommt er nicht mehr an neue Access-Tokens, und kann damit nichts mehr machen.
 

Meeresgott

Bekanntes Mitglied
Ahh okay da ist der Groschen gefallen. Also dient der Refreshtoken mit Accesstoken auch zur Aktualisierung der Berechtigungen nach Änderung. So macht es natürlich wesentlich mehr Sinn.

Der Refreshtoken ist mehr oder minder gleichwertig mit den User Credentials ? Quasi der User gibt einmal seine Login-Daten ein und bekommt "auf ewig" diesen einen Refreshtoken ? Oder unter welchen Umständen ändert dieser sich oder läuft er doch ab?

P.S. Eigentlich auch durch AuthO obsolet interessiert mich allerdings trotzdem: Wenn du die Berechtigung in den Token schreiben würdest welche Szenario würdest du wählen:

Elemtarrechte in den Token und der Service fragt den Token einfach ob er genau das Recht hat was er gerade braucht.

Rollen in den Token und die Services wissen welche Rollen welche Rechte beherbergen.

Oder vielleicht ein drittes ?
 
Zuletzt bearbeitet:
Ähnliche Java Themen
  Titel Forum Antworten Datum
H Authentisierung Allgemeine Java-Themen 4

Ähnliche Java Themen

Neue Themen


Oben