Ich habe ein Szenario, in dem sich ein Benutzer in einer Webanwendung angemeldet hat (authentifiziert mit OpenID Connect) und dann auf Daten von einem separaten REST-Dienst zugreifen muss.
Der REST-Service muss ermitteln, ob der Benutzer berechtigt ist, auf die angeforderten Daten zuzugreifen. Wenn der Benutzer jedoch berechtigt ist, sollte er der Webanwendung die Berechtigung erteilen, ohne dass der Benutzer mit der Benutzeroberfläche interagieren muss.
Im Wesentlichen benötige ich eine zweibeinige OAuth-Lösung, bei der der Client / die vertrauende Seite vollständig vertrauenswürdig ist, der Benutzer jedoch, der bereits authentifiziert wurde, nicht.
Ich ging davon aus, dass OAuth diese Anforderungen erfüllen konnte, aber keiner der Grant-Typen scheint den Anforderungen zu entsprechen:
Ist das eine Lücke in OAuth? Oder verstehe ich diese Grant-Typen falsch? Wenn OAuth dieses Szenario nicht unterstützen kann, gibt es einen weiteren weit verbreiteten offenen Standard, den ich übersehen habe?
Zu beachten: Ich besitze / kontrolliere nur die Webanwendung, während die Kunden (die alle Unternehmen sind) sowohl die Authentifizierungsserver als auch die REST-Dienste besitzen / kontrollieren. Daher ist ein gemeinsamer, nicht proprietärer Standard erforderlich, damit unsere Kunden wissen, wie sie ihre Dienste konfigurieren (IBM, Microsoft, was auch immer) und damit ich alle Authentifizierungstoken usw. weitergeben kann.
Ich denke, das ist mit normalen OAuth2-Flows möglich. Ihre Webanwendung verwendet die Autorisierungsberechtigung für Code , um ein Token zum Aufruf der API im Namen zu erhalten des Benutzers.
Ihre Webanwendung führt den Aufruf der API aus, die das JWT-Token im Autorisierungsheader anfügt. Wenn der REST-Service feststellt, dass der Benutzer keine Berechtigung zum Zugriff auf die Ressource hat, gibt er einen 401 Nicht autorisierten HTTP-Antwortcode zurück.
Ihre Webanwendung verarbeitet die Antwort 401, indem sie zum Autorisierungsserver zurückkehrt und die Clientanmeldeinformationen gewähren
Da beide Grants Ihnen erlauben, ein Refresh-Token zu erhalten, sollten Sie in der Lage sein, einfach zwischen Zugriffstoken zu wechseln.
Wenn zwischen der Webanwendung und dem REST-Dienst keine Vertrauensstellung besteht, gibt es keine Möglichkeit, die Autorisierungscode-Berechtigung zu verwenden, da der Benutzer trotzdem beteiligt sein muss, damit die Webanwendung den Aufruf im Namen des Benutzers ausführen kann.
Wenn zwischen der Webanwendung und dem REST-Dienst eine Vertrauensbeziehung besteht, können Sie den regulären OpenID Connect-Flow verwenden, um bei der Anmeldung ein Zugriffstoken für die Webanwendung zu erhalten, das auch für Anrufe an den REST-Dienst verwendet werden kann.
Sie können die Benutzerinformationen als Teil eines JWT (d. h. eines strukturierten) Zugriffstokens weitergeben, das von der Webanwendung selbst oder dem OP signiert wurde. das wäre OAuth 2.0-konform. Siehe Ссылка und Darf ein OAuth 2.0-Zugriffstoken eine JWT sein? .
Tags und Links authentication rest authorization oauth-2.0