Die Punkte verbinden: Eine ausführliche Erforschung von OIDC-Ressourcen und Ihren JWT-Zugriffstokens

Hintergrund#

In einer vorherigen Session haben wir eine Einführung in das OpenID Connect (OIDC) Protokoll, Auffrischungstokens, Zugriffstokens und ID-Tokens gegeben, wesentliche Komponenten für den Aufbau einer robusten Authentifizierung in Ihrer Anwendung. Es gibt jedoch immer noch offene Fragen in unserer Gemeinschaft, besonders eine immer wiederkehrende Anfrage: "Warum ist mein Zugriffstoken kein JWT?”

Dieser Blog-Post soll Licht auf das Verhältnis zwischen OIDC-Ressourcenindikatoren und ihrer Rolle bei der Beschaffung von Zugriffstokens werfen.

Verständnis der OIDC-Ressource#

Wenn Sie mit dem OAuth 2.0-Protokoll vertraut sind, sollte der Begriff “Ressource” ein Begriff sein. Da OIDC auf OAuth 2.0 basiert, übernimmt es dieses Konzept.

Eine "Ressource" oder "geschützte Ressource" ist eine Darstellung einer Entität, auf die die Client-Anwendung im Namen des authentifizierten Benutzers zugreifen möchte. Dies könnte Benutzerinformationen, Server-APIs oder andere vom Server autorisierte Daten sein.

Nach dem Protokoll ist die Ressource ein Parameter in Anfragen an den Autorisierungsserver. Es ist ein Wert, der als absolute URI dargestellt wird, zum Beispiel https://my-company.com/api. Es fungiert als Identifier für die Ressource, möglicherweise entspricht es einem netzwerkadressierbaren Ort oder sogar einer eindeutigen, aber fiktiven URI.

In Logto können Sie eine „API-Ressource“ über die Seite „Admin-Konsole → API-Ressourcen“ erstellen. Sie können sich auf diese Dokumentation für weitere Details beziehen.

JWT-Zugriffstoken#

Das JWT (JSON-Web-Token) Format Zugriffstoken wird nur ausgegeben, wenn der "Ressourcen"-Parameter bei der Zugriffstoken-Anforderung angegeben ist, und es trägt eine Reihe von Ansprüchen, die Sie entschlüsseln und validieren können, zum Beispiel um die Integrität des Tokens und die Berechtigungen des Benutzers sicherzustellen.

Diese "Ressource" wird dann zu einem der aud Token-Ansprüche im JWT, der das beabsichtigte Publikum für das Token anzeigt. Siehe RFC-7519.

Die Beziehung wird also klar:

• Geben Sie den Ressourcenindikator an, wenn Sie ein JWT-Token anfordern.
• Der Ressourcenindikator stimmt mit dem aud Token-Anspruch überein.
• Bei API-Anfragen muss das JWT-Zugriffstoken als Träger-Token-Header enthalten sein. Ihr API-Server sollte den aud Anspruch und andere berechtigungsbezogene Ansprüche entschlüsseln und validieren, um die API-Anfrage zu sichern.
• Jedes Zugriffstoken entspricht einer einzelnen Ressource. Wenn Sie mehrere API-Ressourcen mit unterschiedlichen URIs registriert haben, fordern Sie unterschiedliche Zugriffstokens für jede an.

🤔 Aber was ist, wenn der Client die Ressource bei der Anforderung des Zugriffstokens nicht angibt?

Undurchsichtiges Zugriffstoken#

Im Fall von Logto, wenn der Ressourcenindikator beim Anfordern des Zugriffstokens nicht angegeben wird, geht der Autorisierungsserver davon aus, dass es für den OIDC /userinfo Endpunkt bestimmt ist. Daher wird ein undurchsichtiges Zugriffstoken ausgestellt, das später vom Client verwendet werden kann, um Benutzerprofile wie Benutzer-ID, Name, E-Mail usw. vom OIDC userinfo Endpunkt zu fordern.

In jedem Logto SDK können Sie ein solches Token erhalten, wenn Sie getAccessToken() aufrufen oder direkt den OIDC-Token-Endpunkt anfordern, ohne den Ressourcen-Parameter anzugeben.

Beachten Sie, dass dieses undurchsichtige Zugriffstoken nicht für Ihre eigenen API-Ressourcenanfragen geeignet ist, da es keine Möglichkeit gibt, es zu überprüfen, ohne den OIDC-Server zu befragen.

Zusammenfassung#

Die OIDC-Ressourcen definieren bestimmte Daten oder Dienste, auf die eine Client-Anwendung im Auftrag des Benutzers zugreifen möchte, wobei JWT-Zugriffstokens als sicheres Mittel für diesen Zugang dienen. Der "aud"-Anspruch in JWT-Zugriffstokens stimmt mit dem Ressourcenindikator überein und hilft Servern dabei, Berechtigungen bei Client-Anfragen zu überprüfen.

In Logto ist das undurchsichtige Zugriffstoken ausschließlich dafür vorgesehen, Benutzerprofilinformationen vom OIDC userinfo Endpunkt abzurufen, während Clients mehrere Zugriffstokens anfordern können, die jeweils einer spezifischen Ressource gewidmet sind.

Wir hoffen, dass dieser Blog-Post Ihre Zweifel beseitigt und die Punkte für Sie miteinander verbindet. Zögern Sie nicht, uns Ihre Gedanken mitzuteilen.