{"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 zu IdentityServer4 er\u00f6ffnen. Wir beginnen mit den wichtigsten Begriffen.<\/p>\n

<\/p>\n

Das vielversprechendste Authentifizierungsprotokoll in der heutigen Zeit ist OpenID Connect<\/a><\/noindex>, w\u00e4hrend das Autorisierungsprotokoll (Zugangsgew\u00e4hrung) ist OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implementiert diese beiden Protokolle. Es ist optimiert, um typische Probleme zu l\u00f6sen.<\/strong> der Sicherheit.<\/p>\n

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

OpenID Connect<\/a><\/noindex> \u2014 es ist ein Protokoll und ein Standard f\u00fcr die Authentifizierung, es gew\u00e4hrt keinen Zugriff auf Ressourcen (Web-API), aber da es \u00fcber dem Autorisierungsprotokoll entwickelt wurde, OAuth 2.0<\/a><\/noindex>erm\u00f6glicht es, die Benutzerdatenparameter zu erhalten, als ob Sie Zugriff auf die Ressource erhalten h\u00e4tten. UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) ist ein Webstandard, der definiert, wie Benutzerdaten im JSON-Format verschl\u00fcsselt \u00fcbertragen werden.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 ist ein Protokoll und ein Standard f\u00fcr die Autorisierung. Es erm\u00f6glicht Anwendungen, auf gesch\u00fctzte Ressourcen zuzugreifen, z. B. auf Web-APIs.<\/p><\/blockquote>\n

Lassen Sie uns das Diagramm zum Zugriff auf eine gesch\u00fctzte Ressource betrachten und die wichtigsten Schritte sowie die verwendete Terminologie erl\u00e4utern:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Der Client fragt den Benutzer um Erlaubnis, sich in seinem Namen zu authentifizieren. den Kunden zur\u00fcckzuf\u00fchren sind, nicht verf\u00fcgbar ist.<\/strong> \u2014 ist die Clientanwendung, die im Namen des Ressourceninhabers auf gesch\u00fctzte Ressourcen zugreift. Ressource<\/strong> \u2014 das sind all unsere gesch\u00fctzten Dienste. Web-API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    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\u00fcr die Clientanwendung. Benutzer (Ressourceninhaber)<\/strong> \u2014 ist ein Programm oder eine Person, die Zugriff auf gesch\u00fctzte Ressourcen gew\u00e4hren kann, z. B. durch Eingabe von Benutzernamen (username) und Passwort (password);<\/p>\n

    \n<\/li>\n

  3. \n

    Die Clientanwendung fordert ein Zugriffstoken von IdentityServer4<\/code> an, indem sie Informationen \u00fcber sich selbst bereitstellt (client_id<\/code>, client_secret<\/code>), um die Erlaubnis zur Autorisierung vom Benutzer zu erlangen (username<\/code>, passwort<\/code>) und gibt grant_type<\/code> und scope<\/code>. Dann \u00fcberpr\u00fcft der Autorisierungsserver die Authentizit\u00e4t des Clients und die Anmeldedaten des Ressourceninhabers (Benutzername und Passwort). <\/p>\n

    <\/p>\n

    Das OAuth 2.0-Protokoll f\u00fchrt 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<\/strong> und client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 dies ist die Kennung der Clientanwendung, die verwendet wird, IdentityServer4<\/code> um Informationen \u00fcber den Client zu finden.
    \nclient_secret<\/strong> ist das \u00c4quivalent eines Passworts f\u00fcr die Clientanwendung und wird zur Authentifizierung der Clientanwendung genutzt. IdentityServer4<\/code>. Das Geheimnis des Kunden sollte nur der Anwendung und der API bekannt sein.<\/strong>Aus dem Vorangegangenen schlie\u00dfen wir, dass IdentityServer4 \u00fcber seine Clients Bescheid wissen muss.<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

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

    \n<\/li>\n

  5. \n

    Die Client-Anwendung fordert Daten vom gesch\u00fctzten Web-API an, wobei sie das Zugriffstoken zur Autorisierung bereitstellt. Wenn der Antwortcode des Ressourcenservers 401<\/a><\/noindex>, 403<\/a><\/noindex> oder 498<\/a><\/noindex>ist, ist das zur Authentifizierung verwendete Zugriffstoken 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

    Registrierte Clients d\u00fcrfen bei IdentityServer4<\/code> identity IdentityServer4<\/code> -Token,<\/code>Access -Token und<\/code>Refresh -Token anfordern.<\/code>Identity-Token (Identifikationstoken)<\/p>\n

    <\/p>\n