WebAPI Impliziten Datenfluss und Client-Anmeldeinformationsfluss mischen

Ich habe eine WebAPI-Lösung, die die Controller-Methoden über das Attribut [Authorize] absichert. Es wird überprüft, ob ein bestimmter Benutzer über die entsprechenden Rollen verfügt, bei denen es sich im Grunde um Angaben handelt, die von einem IdentityServer3 stammen.

Es gibt mehrere Anwendungsclients mit einer Seite, die mit t, seiner WebAPI und den Clientbenutzern interagieren, die mithilfe des impliziten Datenflusses authentifiziert / autorisiert werden.

So weit ziemlich Standard und einfach, alles funktioniert gut ...

Now Ich benötige einen Hintergrundprozess, um auf dasselbe WebAPI zuzugreifen. Dies wird effektiv zu einer Maschine-zu-Maschine-Kommunikation. Basierend auf der gesamten Dokumentation, die ich gelesen habe, ist dies eine Situation für den Clientanmeldeinformationsfluss. Es sind keine Benutzer beteiligt.

Das Problem..

Wenn kein Benutzer beteiligt ist, bedeutet dies auch kein Thema, keine Ansprüche und offensichtlich keine Rollen. Wenn ich mich nicht irre, hat ein Kunde keine Ansprüche. Wie kann dann ein Client wie dieser autorisiert werden, den Dienst / die Ressource zu verwenden, da meine Controller-Methoden durch Rollen gesichert sind?

Ich habe gelesen, dass ein Client nur einen Flow haben sollte, aber was ist mit einer Ressource? Der vom Client verwendete Flow sollte für die Ressource nicht wichtig sein, mit der Ausnahme, dass für das Zugriffstoken je nach Client-Flow keine Ansprüche geltend gemacht werden. In diesem Zusammenhang ist der Datenfluss auch für eine Ressource relevant, wenn er durch Ansprüche gesichert ist. Bin ich verwirrt?

Soll ich einen neuen Dienst speziell für den Clientanmeldeinformationsfluss erstellen? Den Identitätsserver manipulieren, um Ansprüche auf Clients zu unterstützen?

Ich suche hier nach Best Practices.

Bearbeite

Bitte beachten Sie auch diese Github-Diskussion ...Ausgabe 76

Wenn das Thema null ist, ist kein Mensch beteiligt.

Wir planen keine Ansprüche für Kunden. Die Client-Identität und der Gültigkeitsbereich sollten ausreichen.

leastprivilege

Siehe auch ...Ausgabe 79

Well - Im Allgemeinen sollte ein Client nur einen Flow haben, da dies zu Sicherheitsproblemen führen kann, wenn die falsche Kombination von Flows konfiguriert ist (z. B. Code und implizit).

leastprivilege

Antworten auf die Frage(2)

Ihre Antwort auf die Frage