IdentityServer4. Grundbegriffe. OpenID Connect, OAuth 2.0 und JWT

Mit diesem Beitrag möchte ich eine Reihe von Artikeln über IdentityServer4 einleiten. Lassen Sie uns mit den grundlegenden Begriffen beginnen.

Der vielversprechendste Authentifizierungsprotokoll ist derzeit OpenID Connect, während das Protokoll für die Autorisierung (Zugriffsgewährung) ist OAuth 2.0. IdentityServer4 implementiert diese beiden Protokolle. Es ist optimiert zur Lösung von typischen Sicherheitsproblemen. — ist ein Protokoll und Standard für die Authentifizierung, es gewährt keinen Zugriff auf Ressourcen (Web-API), aber da es auf dem Autorisierungsprotokoll basiert

OpenID Connect , ermöglicht es die Abrufung der Benutzerprofilparameter, als ob Sie Zugang zu der Ressource erhalten hätten. OAuth 2.0UserInfo JWT.

(JSON Web Token) ist ein Webstandard, der definiert, wie Benutzerdaten in verschlüsselter Form im JSON-Format übermittelt werden. OAuth 2.0 (RFC 6749)

— ist das Protokoll und der Standard für die Autorisierung. Es ermöglicht Anwendungen den Zugriff auf geschützte Ressourcen, zum Beispiel auf Web-APIs. Werfen wir einen Blick auf das Diagramm zum Zugriff auf eine geschützte Ressource und klären wir die wichtigsten Schritte und die verwendete Terminologie:

Der Client fragt den Benutzer um Erlaubnis, sich in seinem Namen zu authentifizieren.

1. Der Kunde bittet den Benutzer um Erlaubnis, sich in seinem Namen zu authentifizieren. Kunde ist eine Client-Anwendung, die im Namen des Ressourcenbesitzers auf geschützte Ressourcen zugreift. Ressource sind all unsere geschützten Dienste. Web API.

2. Der Benutzer erlaubt der Client-Anwendung, sich in seinem Namen zu authentifizieren, beispielsweise durch Eingabe von Benutzername und Passwort. Benutzername und Passwort dienen als Authentifizierungsnachweis für die Client-Anwendung. Benutzer (Ressourcenbesitzer) ist ein Programm oder eine Person, die Zugang zu geschützten Ressourcen gewähren kann, zum Beispiel durch Eingabe von Benutzername und Passwort;

3. Die Client-Anwendung fordert ein Zugriffstoken bei IdentityServer4 an, indem sie Informationen über sich selbst bereitstellt (client_id, client_secret), die Erlaubnis zur Authentifizierung durch den Benutzer erteilt (Benutzername, password) und angibt, grant_type und scope. Anschließend überprüft der Autorisierungsserver die Authentizität des Clients und die Anmeldedaten des Ressourcenbesitzers (Benutzername und Passwort).

   Das OAuth 2.0-Protokoll ermöglicht die Authentifizierung nicht nur des Benutzers, sondern auch der Client-Anwendung, die auf die Ressourcen zugreift. Dazu sieht das Protokoll solche Parameter wie vor: client_id und client_secret.
   client_id ist die Kennung der Client-Anwendung, die verwendet wird, IdentityServer4 um Informationen über den Client zu suchen.
   client_secret ist das Äquivalent eines Passworts für die Clientanwendung und wird zur Authentifizierung der Clientanwendung bei IdentityServer4. Der Client-Geheimschlüssel sollte nur der Anwendung und der API bekannt sein.. Daraus ergibt sich, dass IdentityServer4 über seine Clients informiert sein muss..

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

5. Die Clientanwendung ruft Daten vom geschützten Web-API ab und stellt dabei das Zugangstoken zur Autorisierung bereit. Wenn der Server eine Ressource mit dem Antwortcode 401, 403 oder 498, ist das für die Authentifizierung verwendete Zugangstoken ungültig oder abgelaufen.

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

Token-Typen

Registrierten in IdentityServer4 dürfen Clients bei IdentityServer4 identity-Token, Access-Token und aktualisieren-Token anfordern.

• Identity-Token (Identifikations-Token) — Ergebnis des Authentifizierungsprozesses. Enthält die Benutzer-ID und Informationen darüber, wie und wann der Benutzer authentifiziert wird. Kann mit eigenen Daten erweitert werden.
• Zugriffstoken (access token) — wird an die geschützte API übermittelt und von dieser verwendet, um den Zugriff auf ihre Daten zu autorisieren.
• Aktualisierungstoken (refresh token) — optionaler Parameter, den der Autorisierungsserver als Antwort auf eine Anfrage nach einem Zugriffstoken zurückgeben kann.

Lassen Sie uns zwei weitere Begriffe einführen:

Authentifizierungsserver-URL — Endpunkt zum Abrufen des Zugriffstokens. Alle Anfragen zur Bereitstellung und Erneuerung des Zugriffstokens werden an diese URL gesendet.

Ressourcen-URL — die URL des geschützten Ressourcen, auf die zugegriffen werden muss, indem das Zugriffstoken im Autorisierungs-Header übergeben wird.

Anfrage des Zugriffstokens

Um das Zugriffstoken anzufordern, stellt der Client POST eine Anfrage an den Endpunkt IdentityServer4 mit folgendem Header

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

und übermittelt die folgenden Parameter:

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

Benutzername, password, client_id und client_secret wurden oben behandelt. Lassen Sie uns die anderen Parameter betrachten:

grant_type — Grant-Typ oder Autorisierungsgrant-Typ. Der Autorisierungsgrant-Typ hängt von der im Anwendung verwendeten Methode zur Anforderung der Autorisierung ab sowie davon, welche Grant-Typen vom API unterstützt werden. In unserem Fall wird er den Wert haben password, was gemäß der Spezifikation OAuth 2.0 dem Grant von Zugangsdaten des Ressourceninhabers entspricht (Autorisierung über Benutzername und Passwort).

Protokoll OAuth 2.0 bestimmt die folgenden Grant-Typen, die erfordern ein zwingendes Interagieren mit Benutzern:

• Authorization Code. Dies ist einer der am weitesten verbreiteten Typen von Autorisierungsgrants, da er sich gut für serverseitige Anwendungen eignet, bei denen der Quellcode der Anwendung und das Client-Geheimnis Dritten nicht zugänglich sind;
• implizit. Der implizite Autorisierungsgrant wird in mobilen und Webanwendungen verwendet, wo die Vertraulichkeit des Client-Geheimnisses nicht garantiert werden kann;

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

• Zugangsdaten des Ressourceninhabers. Diese Art der Authentifizierung sollte nur verwendet werden, wenn die Client-Anwendung das Vertrauen des Benutzers genießt und der Benutzer bereit ist, seine Anmeldedaten einzugeben. Diese Art der Authentifizierung sollte nur genutzt werden, wenn keine anderen Optionen verfügbar sind. Sie ist besonders nützlich für Unternehmenskunden, die in ihrem System bereits Benutzerdaten verwendet haben und zu OAuth 2.0.
• Benutzerdaten. Diese werden benötigt, wenn die Anwendung auf die API zugreift. Dies kann nützlich sein, wenn beispielsweise die Anwendung ihre eigenen Registrierungsinformationen beim Dienst aktualisieren oder eine Umleitungs-URI festlegen möchte, oder um auf andere Informationen zuzugreifen, die im Benutzerkonto der Anwendung beim Dienst über die API gespeichert sind.

scope — ist ein optionales Parameter. Es definiert den Geltungsbereich. Das Zugriffstoken, das vom Server zurückgegeben wird, gewährt Zugriff nur auf die Dienste, die in diesen Geltungsbereich fallen. Das heißt, wir können mehrere Dienste unter einem einzigen Geltungsbereich zusammenfassen und wenn der Kunde einen Zugangsschlüssel zu diesem Geltungsbereich erhält, hat er Zugang zu allen diesen Diensten. Der Geltungsbereich kann auch verwendet werden, um die Berechtigungen zu beschränken (z. B. Lese- oder Schreibzugriff).

Quelle: habr.com