IdentityServer4. Grundbegriffe. OpenID Connect, OAuth 2.0 und JWT

Mit diesem Beitrag möchte ich eine Reihe von Artikeln zu IdentityServer4 eröffnen. Wir beginnen mit den wichtigsten Begriffen.

Das vielversprechendste Authentifizierungsprotokoll in der heutigen Zeit ist OpenID Connect, während das Autorisierungsprotokoll (Zugangsgewährung) ist OAuth 2.0. IdentityServer4 implementiert diese beiden Protokolle. Es ist optimiert, um typische Probleme zu lösen. der Sicherheit.

OpenID Connect — es ist ein Protokoll und ein Standard für die Authentifizierung, es gewährt keinen Zugriff auf Ressourcen (Web-API), aber da es über dem Autorisierungsprotokoll entwickelt wurde, OAuth 2.0ermöglicht es, die Benutzerdatenparameter zu erhalten, als ob Sie Zugriff auf die Ressource erhalten hätten. UserInfo.

JWT (JSON Web Token) ist ein Webstandard, der definiert, wie Benutzerdaten im JSON-Format verschlüsselt übertragen werden.

OAuth 2.0 (RFC 6749) — ist ein Protokoll und ein Standard für die Autorisierung. Es ermöglicht Anwendungen, auf geschützte Ressourcen zuzugreifen, z. B. auf Web-APIs.

Lassen Sie uns das Diagramm zum Zugriff auf eine geschützte Ressource betrachten und die wichtigsten Schritte sowie die verwendete Terminologie erläutern:

1. Der Client fragt den Benutzer um Erlaubnis, sich in seinem Namen zu authentifizieren. den Kunden zurückzuführen sind, nicht verfügbar ist. — ist die Clientanwendung, die im Namen des Ressourceninhabers auf geschützte Ressourcen zugreift. Ressource — das sind all unsere geschützten Dienste. Web-API.

2. Der Benutzer erlaubt der Clientanwendung, sich in seinem Namen zu authentifizieren, indem er z. B. seinen Benutzernamen und sein Passwort eingibt. Benutzername und Passwort dienen als Autorisierungsgrant für die Clientanwendung. Benutzer (Ressourceninhaber) — ist ein Programm oder eine Person, die Zugriff auf geschützte Ressourcen gewähren kann, z. B. durch Eingabe von Benutzernamen (username) und Passwort (password);

3. Die Clientanwendung fordert ein Zugriffstoken von IdentityServer4 an, indem sie Informationen über sich selbst bereitstellt (client_id, client_secret), um die Erlaubnis zur Autorisierung vom Benutzer zu erlangen (username, passwort) und gibt grant_type und scope. Dann überprüft der Autorisierungsserver die Authentizität des Clients und die Anmeldedaten des Ressourceninhabers (Benutzername und Passwort).

   Das OAuth 2.0-Protokoll führt nicht nur die Authentifizierung des Benutzers durch, sondern auch der Clientanwendung, die auf die Ressourcen zugreift. Zu diesem Zweck sieht das Protokoll Parameter wie vor. client_id und client_secret.
   client_id — dies ist die Kennung der Clientanwendung, die verwendet wird, IdentityServer4 um Informationen über den Client zu finden.
   client_secret ist das Äquivalent eines Passworts für die Clientanwendung und wird zur Authentifizierung der Clientanwendung genutzt. IdentityServer4. Das Geheimnis des Kunden sollte nur der Anwendung und der API bekannt sein.Aus dem Vorangegangenen schließen wir, dass IdentityServer4 über seine Clients Bescheid wissen muss..

4. Wenn die Authentizität der Anwendung bestätigt ist und die Berechtigung zur Autorisierung gültig ist, IdentiryServer4 erstellt ein Access-Token (Zugriffstoken) für die Anwendung und einen optionalen Refresh-Token (Refresh-Token). Der Autorisierungsprozess ist abgeschlossen. Wenn die Anfrage ungültig oder nicht autorisiert ist, gibt der Autorisierungsserver einen Code mit einer entsprechenden Fehlermeldung zurück.

5. Die Client-Anwendung fordert Daten vom geschützten Web-API an, wobei sie das Zugriffstoken zur Autorisierung bereitstellt. Wenn der Antwortcode des Ressourcenservers 401, 403 oder 498ist, ist das zur Authentifizierung verwendete Zugriffstoken ungültig oder abgelaufen.

6. Wenn das Token gültig ist, Web-API stellt es der Anwendung die Daten zur Verfügung.

Token-Typen

Registrierte Clients dürfen bei IdentityServer4 identity IdentityServer4 -Token,Access -Token undRefresh -Token anfordern.Identity-Token (Identifikationstoken)

• — das Ergebnis des Authentifizierungsprozesses. Es enthält die Benutzer-ID und Informationen darüber, wie und wann der Benutzer authentifiziert wird. Kann um eigene Daten erweitert werden. Access-Token (Zugriffstoken)
• — wird an die geschützte API übergeben und von dieser zur Autorisierung (Zugriffsberechtigung) auf ihre Daten verwendet. Refresh-Token (Aktualisierungstoken)
• — ein optionaler Parameter, den der Autorisierungsserver als Antwort auf die Anfrage nach einem Zugriffstoken zurückgeben kann. Führen wir noch zwei Begriffe ein:

Authentification Server URL

— der Endpunkt zur Beschaffung des Zugriffstokens. Alle Anfragen zur Bereitstellung und Erneuerung von Zugriffstokens richten wir an diese URL. Resource URL

— die URL des geschützten Ressourcen, auf die zugegriffen werden muss, indem das Zugriffstoken im Autorisierungsheader übergeben wird. Anfrage nach dem Zugriffstoken

Um den Zugriffstoken zu beantragen, macht der Client

eine Anfrage an den Endpunkt POST mit folgendem Header IdentityServer4 'Content-Type': 'application/x-www-form-urlencoded', 'Accept': 'application/json', 'Expect': '100-continue'

und übergibt die folgenden Parameter:

'grant_type' : 'password', 'username' : login, 'password' : password, 'scope' : 'scope', 'client_id' : 'client_id', 'client_secret' : '{client_secret}'

wurden oben behandelt. Lassen Sie uns die verbleibenden Parameter durchgehen:

username, passwort, client_id und client_secret wurden oben erläutert. Lassen Sie uns die anderen Parameter betrachten:

grant_type — Art des Grants oder des Autorisierungsberechtigungen. Die Art der Autorisierungsberechtigung hängt von der verwendeten Methode zur Anforderung der Autorisierung durch die Anwendung ab, ebenso davon, welche Berechtigungen von der API unterstützt werden. In unserem Fall wird es bedeuten passwort, was gemäß der Spezifikation OAuth 2.0 der Berechtigung des Ressourceninhabers (Autorisation durch Login und Passwort) entspricht.

Protokoll OAuth 2.0 bestimmt die folgenden Grant-Typen, die eine zwingende Interaktion mit den Benutzern erfordern:

• Autorisierungscode (authorization code). Dies ist einer der am häufigsten verwendeten Typen von Autorisierungsberechtigungen, da er gut für serverseitige Anwendungen geeignet ist, bei denen der Quellcode der Anwendung und das Client-Geheimnis für Dritte nicht zugänglich sind.
• implizit (implicit). Der implizite Typ der Autorisierungsberechtigung wird von mobilen und Webanwendungen verwendet, bei denen die Vertraulichkeit des Client-Geheimnisses nicht garantiert werden kann.

Und die Grant-Typen, die ohne interaktive Interaktion mit den Benutzern ausgeführt werden können,:

• Ressourceninhaberdaten (resource owner). Dieser Typ der Autorisierung sollte nur verwendet werden, wenn die Client-Anwendung das Vertrauen des Benutzers genießt und der Benutzer mit der Eingabe seines Logins und Passworts einverstanden ist. Dieser Typ der Autorisierung sollte nur verwendet werden, wenn andere Optionen nicht verfügbar sind. Dieser Autorisierungstyp ist für Unternehmenskunden nützlich, die bereits in ihrem System die Benutzerdaten verwendet haben und zu OAuth 2.0.
• Kundendaten. Verwendet, wenn eine Anwendung auf die API zugreift. Dies kann nützlich sein, beispielsweise wenn die Anwendung ihre eigenen Registrierungsinformationen auf dem Dienst oder der URI für die Weiterleitung aktualisieren oder auf andere Informationen zugreifen möchte, die im Konto der Anwendung auf dem Dienst über die API des Dienstes gespeichert sind.

scope Dies ist ein optionaler Parameter. Er definiert den Gültigkeitsbereich. Das vom Server zurückgegebene Zugriffstoken gewährt Zugriff nur auf die Dienste, die in diesen Gültigkeitsbereich fallen. Das heißt, wir können mehrere Dienste unter einem einzigen Gültigkeitsbereich zusammenfassen, und wenn der Client einen Zugriffsschlüssel für diesen Gültigkeitsbereich erhält, hat er Zugriff auf all diese Dienste. Der Gültigkeitsbereich kann auch verwendet werden, um die Berechtigungen einzuschränken (zum Beispiel Lese- oder Schreibzugriff).

Quelle: habr.com