Ich erstelle eine .NET Core-Lösung basierend auf dem Quickstart IdentityServer ASP.NET Identity. Ich verwende separate Projekte für einen IdentityServer, eine API und einen SPA-Client. Die Authentifizierung funktioniert einwandfrei, aber ich habe eine Frage zu den Best Practices für die Gesamtsystemarchitektur und die gemeinsame Nutzung von Daten zwischen den Projekten IdentityServer und API.Gemeinsame Nutzung von Benutzerinformationen über mit Identity Server gesicherte Clients
Angenommen, ich habe die folgende vereinfachte Datenschema in meiner Lösung:
class User : IdentityUser
{
public string FavoriteColor { get; set; }
}
class SomeObject
{
public string OwnerId { get; set; }
public virtual User Owner { get; set; }
}
Nehmen wir nun an UserA erstellt ein Konto erstellt (und einen User Datensatz) mit dem IdentityServer, meldet sich mit Hybridfluss in und ruft ein access_token, das zur Authentifizierung mit der API verwendet werden kann. UserA ruft dann den Endpunkt API/some objects auf der API auf, der eine Liste aller SomeObject s zurückgeben soll. Der SPA zeigt die Liste SomeObject für BenutzerA an, einschließlich der SomeObject.Owner.FavoriteColor-Eigenschaft für jedes Objekt.
Um die SomeObject.Owner.FavoriteColor Daten zurückzugeben, benötigt die API Zugriff auf den User Speicher. Also, meine Frage ist das: Was ist die empfohlene Möglichkeit, User Daten zwischen dem IdentityServer und der API zu teilen? Sollte die API Zugriff auf dieselben Benutzerdaten haben, die der IdentityServer verwendet? Sollte jeder dieselbe Datenbank verwenden und verwendet IdentityServer einfach die Tabelle User und die API verwendet die Tabellen User und SomeObject?
Wie passt die Datenbank in die IdentityServer-, API- und SPA-Architektur? Eins geteilt? Gibt es zwei? Wenn Best Practice den Benutzerspeicher mit der API nicht sicher ist, benötige ich ein zusätzliches Datenmodell zum Speichern von Benutzerinformationen in der API?
Danke.
IdentityServer behandelt nur Authentifizierung/Autorisierung. Es ist kein Benutzerverwaltungssystem. Wenn Sie sich mit einem Flow authentifizieren, der den Benutzer verwendet (d. H. Nicht wie Client-Authentifizierung, da Clients nicht dasselbe sind wie Benutzer), erhalten Sie eine Benutzer-ID zurück. Sie können diese Benutzer-ID dann verwenden, um entsprechende Änderungen in Ihrer Datenbank vorzunehmen/den Benutzer anhand dieser ID aus Ihrer Datenbank zu suchen. Also, im Allgemeinen benötigen beide Systeme Zugriff auf die Datenbank. –