Laden...

Token-Authentifizierung ohne IdentityServer skalieren

Erstellt von Rioma vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.391 Views
R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 6 Jahren
Token-Authentifizierung ohne IdentityServer skalieren

Hallo zusammen,

was ist der übliche Weg um einen REST-Service mit Token-Authentifizierung zu skalieren?

Ich muss natürlich sicherstellen, dass ein Benutzer mit jedem Backendseitigem Service sprechen kann, egal bei welchem er sich angemeldet hat.

Daher muss das Token von jedem Service für gültig gehalten werden.

Es wird zurzeit kein eigenständiger IdentityServer eingesetzt, sondern eine relativ kleine Bibliothek: ASP.NET.OpenId die in der eigentlichen Applikation sitzt.

Was habe ich nun für Möglichkeiten?

  1. Token auf Basis eines festen Zertifikats erstellen. Das Zertifikat bekommt dann jede Instanz des Services und sollte so kompatible Tokens erzeugen
  2. Ich habe ansetze mit Redis als "Key-Store" gesehen

Habt ihr Erfahrungen und könntet mich beraten?

Vielen Dank

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Rioma,

zurzeit kein eigenständiger IdentityServer eingesetzt

warum nicht? Mit dem wäre das Problem schon gelöst.

Hast du dann bei deiner OpenId-Variante ein Authentifizierung gegen was?
Ein gängiger Weg ist dann den gleichen "Schlüssel" bei allen Maschinen zu verwenden. Das wäre z.B. dein Zertifikat-Vorschlag.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 6 Jahren

warum nicht? Mit dem wäre das Problem schon gelöst.

Das Backend hat einen kleinen Funktionsumfang und muss relativ häufig installiert werden (Jedes mal liegt eine andere Datenbank mit Benutzern dahinter). Um den Aufwand möglichst gering zu halten, wurde sich damals für das Paket AspNet.Security.OpenIdConnect.Server entschieden, was mit dem Backend ausgeliefert wird.
Außerdem würde ein für sich laufender IdentityServer die Ausfallsicherheit nicht besonders erhöhen, da nun lediglich der IdentityServer ausfallen müsste, um die Applikation unbrauchbar zu machen.

warum nicht? Mit dem wäre das Problem schon gelöst.

Der IdentityServer würde ein Token ausstellen und ich würde in der Web API den IdentityServer als Issuer eintragen. Woher wissen die einzelnen API´s, das dass Token gültig ist? Ich nehme an, der IdentityServer muss nicht bei jedem Request gefragt werden.

Ich durchsuche gerade die Spezifikation des OpenID Connect Protokolls um eine Antwort zu finden. Allerdings wird es mir noch nicht 100% klar.

Hast du dann bei deiner OpenId-Variante ein Authentifizierung gegen was?

Die Applikation läuft stets in einem internen Netzwerk und die Credentials werden gegen eine Datenbank geprüft. Es ist quasi ein Resource Owner Password Credentials Flow.

Vielen Dank

16.807 Beiträge seit 2008
vor 6 Jahren

Da solltest Du die Basics von Tokens mal anschauen.

OpenId ist für die Authentifizierung.
OAuth 2.0 für die Authorisierung.

Was Du willst ist ein Token, der die Authorisierung gewährleistet.
In Deinem Fall willst Du wohl OAuth 2.0 mit Implicit Flow.

T
415 Beiträge seit 2007
vor 6 Jahren

Woher wissen die einzelnen API´s, das dass Token gültig ist? Ich nehme an, der IdentityServer muss nicht bei jedem Request gefragt werden.

Doch. Genau das muss geschehen.

Wenn ihr nicht zwingend das Ganze als Self-Hosting betreiben müsst, dann wäre es durchaus eine Überlegung wert mal die Dienste von https://auth0.com/ anzuschauen. Damit schützt du deine APIs / Services mit sehr geringen Aufwand. Einfach mal ein paar Tutorials dazu anschauen. Es ist wirklich einfach einzurichten.

R
Rioma Themenstarter:in
228 Beiträge seit 2013
vor 6 Jahren

Alles klar danke.

@Abt dein neues Beispiel auf Github hilft sehr! Github

16.807 Beiträge seit 2008
vor 6 Jahren

Danke fürs Feedback