{"id":71307,"date":"2020-02-24T22:18:55","date_gmt":"2020-02-24T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt"},"modified":"2020-03-03T16:14:27","modified_gmt":"2020-03-03T13:14:27","slug":"identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. Grundbegriffe. OpenID Connect, OAuth 2.0 und JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mit diesem Beitrag m\u00f6chte ich eine Reihe von Artikeln \u00fcber IdentityServer4 einleiten. Lassen Sie uns mit den grundlegenden Begriffen beginnen.<\/p>\n

<\/p>\n

Der vielversprechendste Authentifizierungsprotokoll ist derzeit OpenID Connect<\/a><\/noindex>, w\u00e4hrend das Protokoll f\u00fcr die Autorisierung (Zugriffsgew\u00e4hrung) ist OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implementiert diese beiden Protokolle. Es ist optimiert zur L\u00f6sung von typischen Sicherheitsproblemen.<\/strong> \u2014 ist ein Protokoll und Standard f\u00fcr die Authentifizierung, es gew\u00e4hrt keinen Zugriff auf Ressourcen (Web-API), aber da es auf dem Autorisierungsprotokoll basiert<\/p>\n

<\/a><\/noindex><\/p>\n

OpenID Connect<\/a><\/noindex> , erm\u00f6glicht es die Abrufung der Benutzerprofilparameter, als ob Sie Zugang zu der Ressource erhalten h\u00e4tten. OAuth 2.0<\/a><\/noindex>UserInfo JWT<\/a><\/noindex>.<\/p>\n

(JSON Web Token) ist ein Webstandard, der definiert, wie Benutzerdaten in verschl\u00fcsselter Form im JSON-Format \u00fcbermittelt werden.<\/a><\/noindex> OAuth 2.0 (RFC 6749)<\/p>\n

\u2014 ist das Protokoll und der Standard f\u00fcr die Autorisierung. Es erm\u00f6glicht Anwendungen den Zugriff auf gesch\u00fctzte Ressourcen, zum Beispiel auf Web-APIs.<\/a><\/noindex> Werfen wir einen Blick auf das Diagramm zum Zugriff auf eine gesch\u00fctzte Ressource und kl\u00e4ren wir die wichtigsten Schritte und die verwendete Terminologie:<\/p><\/blockquote>\n

Der Client fragt den Benutzer um Erlaubnis, sich in seinem Namen zu authentifizieren.<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Der Kunde bittet den Benutzer um Erlaubnis, sich in seinem Namen zu authentifizieren. Kunde<\/strong> ist eine Client-Anwendung, die im Namen des Ressourcenbesitzers auf gesch\u00fctzte Ressourcen zugreift. Ressource<\/strong> sind all unsere gesch\u00fctzten Dienste. Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    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\u00fcr die Client-Anwendung. Benutzer (Ressourcenbesitzer)<\/strong> ist ein Programm oder eine Person, die Zugang zu gesch\u00fctzten Ressourcen gew\u00e4hren kann, zum Beispiel durch Eingabe von Benutzername und Passwort;<\/p>\n

    \n<\/li>\n

  3. \n

    Die Client-Anwendung fordert ein Zugriffstoken bei IdentityServer4<\/code> an, indem sie Informationen \u00fcber sich selbst bereitstellt (client_id<\/code>, client_secret<\/code>), die Erlaubnis zur Authentifizierung durch den Benutzer erteilt (Benutzername<\/code>, password<\/code>) und angibt, grant_type<\/code> und scope<\/code>. Anschlie\u00dfend \u00fcberpr\u00fcft der Autorisierungsserver die Authentizit\u00e4t des Clients und die Anmeldedaten des Ressourcenbesitzers (Benutzername und Passwort). <\/p>\n

    <\/p>\n

    Das OAuth 2.0-Protokoll erm\u00f6glicht 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<\/strong> und client_secret<\/strong>.
    \nclient_id<\/strong> ist die Kennung der Client-Anwendung, die verwendet wird, IdentityServer4<\/code> um Informationen \u00fcber den Client zu suchen.
    \nclient_secret<\/strong> ist das \u00c4quivalent eines Passworts f\u00fcr die Clientanwendung und wird zur Authentifizierung der Clientanwendung bei IdentityServer4<\/code>. Der Client-Geheimschl\u00fcssel sollte nur der Anwendung und der API bekannt sein.<\/strong>. Daraus ergibt sich, dass IdentityServer4 \u00fcber seine Clients informiert sein muss.<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Wenn die Authentizit\u00e4t der Anwendung best\u00e4tigt und die Berechtigung zur Autorisierung g\u00fcltig ist, IdentiryServer4<\/code> erstellt ein Access-Token<\/code> (Zugangs-token) f\u00fcr die Anwendung und optional einen Refresh-Token (Refresh-Token<\/code>). Der Autorisierungsprozess ist abgeschlossen. Wenn die Anfrage ung\u00fcltig oder nicht autorisiert ist, gibt der Autorisierungsserver einen Code mit der entsprechenden Fehlermeldung zur\u00fcck.<\/p>\n

    \n<\/li>\n

  5. \n

    Die Clientanwendung ruft Daten vom gesch\u00fctzten Web-API ab und stellt dabei das Zugangstoken zur Autorisierung bereit. Wenn der Server eine Ressource mit dem Antwortcode 401<\/a><\/noindex>, 403<\/a><\/noindex> oder 498<\/a><\/noindex>, ist das f\u00fcr die Authentifizierung verwendete Zugangstoken ung\u00fcltig oder abgelaufen.<\/p>\n

    \n<\/li>\n

  6. \n

    Wenn das Token g\u00fcltig ist, Web API<\/code> stellt es der Anwendung die Daten zur Verf\u00fcgung.<\/p>\n

    \n<\/li>\n<\/ol>\n

    <\/p>\n

    Token-Typen<\/em><\/h4>\n

    <\/p>\n

    Registrierten in IdentityServer4<\/code> d\u00fcrfen Clients bei IdentityServer4<\/code> identity<\/code>-Token, Access<\/code>-Token und aktualisieren<\/code>-Token anfordern.<\/p>\n

    <\/p>\n