{"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\/sv\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. Grundl\u00e4ggande begrepp. OpenID Connect, OAuth 2.0 och JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Med detta inl\u00e4gg vill jag starta en serie artiklar som handlar om IdentityServer4. Vi b\u00f6rjar med de grundl\u00e4ggande begreppen.<\/p>\n

<\/p>\n

Den mest lovande autentiseringsprotokollet just nu \u00e4r OpenID Connect<\/a><\/noindex>, medan auktoriseringsprotokollet (\u00e5tkomstbeviljande) \u00e4r OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implementerar dessa tv\u00e5 protokoll. Det \u00e4r optimerat f\u00f6r att l\u00f6sa typiska s\u00e4kerhetsproblem.<\/strong> s\u00e4kerhet.<\/p>\n

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

OpenID Connect<\/a><\/noindex> \u2014 det \u00e4r ett autentiseringsprotokoll och standard, det ger inte tillg\u00e5ng till resurser (Web API), men eftersom det \u00e4r utvecklat ovanp\u00e5 auktoriseringsprotokollet OAuth 2.0<\/a><\/noindex>, l\u00e5ter det dig h\u00e4mta anv\u00e4ndarprofilens parametrar som om du fick tillg\u00e5ng till resursen UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) \u00e4r en webstandard som definierar hur anv\u00e4ndardata kan \u00f6verf\u00f6ras i JSON-format p\u00e5 ett s\u00e4kert s\u00e4tt.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 det \u00e4r ett auktoriseringsprotokoll och standard. Det till\u00e5ter applikationer att f\u00e5 tillg\u00e5ng till skyddade resurser, till exempel Web API.<\/p><\/blockquote>\n

L\u00e5t oss titta p\u00e5 diagrammet f\u00f6r att f\u00e5 \u00e5tkomst till en skyddad resurs och g\u00e5 igenom de grundl\u00e4ggande stegen och den accepterade terminologin:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Klienten beg\u00e4r tillst\u00e5nd av anv\u00e4ndaren att genomg\u00e5 autentisering \u00e5 hans eller hennes v\u00e4gnar. Klient<\/strong> \u2014 det \u00e4r en klientapplikation som beg\u00e4r \u00e5tkomst till skyddade resurser \u00e5 \u00e4garens v\u00e4gnar. Resurs<\/strong> \u2014 det \u00e4r alla v\u00e5ra skyddade tj\u00e4nster Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    Anv\u00e4ndaren till\u00e5ter klientapplikationen att genomg\u00e5 autentisering \u00e5 hans eller hennes v\u00e4gnar, till exempel genom att ange anv\u00e4ndarnamn och l\u00f6senord. Anv\u00e4ndarnamn och l\u00f6senord kommer att fungera som ett auktoriseringstillst\u00e5nd f\u00f6r klientapplikationen. Anv\u00e4ndare (resurs\u00e4garen)<\/strong> \u2014 ett program eller en person som kan ge \u00e5tkomst till skyddade resurser, till exempel genom att ange anv\u00e4ndarnamn (username) och l\u00f6senord (password);<\/p>\n

    \n<\/li>\n

  3. \n

    Klientapplikationen beg\u00e4r en \u00e5tkomsttoken fr\u00e5n IdentityServer4<\/code> genom att tillhandah\u00e5lla information om sig sj\u00e4lv (client_id<\/code>, client_secret<\/code>), tillhandah\u00e5lla tillst\u00e5nd f\u00f6r autentisering fr\u00e5n anv\u00e4ndaren (username<\/code>, password<\/code>) och tillhandah\u00e5lla grant_type<\/code> och scope<\/code>. Sedan verifierar auktoriseringsservern klientens \u00e4kthet och resurshavaren (anv\u00e4ndarnamn och l\u00f6senord). <\/p>\n

    <\/p>\n

    OAuth 2.0-protokollet autentiserar inte bara anv\u00e4ndaren, utan \u00e4ven klientapplikationen som f\u00e5r \u00e5tkomst till resurser. F\u00f6r detta \u00e4ndam\u00e5l f\u00f6reskriver protokollet parametrar som client_id<\/strong> och client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 det \u00e4r identifieraren f\u00f6r klientapplikationen, som anv\u00e4nds IdentityServer4<\/code> f\u00f6r att h\u00e4mta information om klienten.
    \nclient_secret<\/strong> \u00e4r en motsvarighet till l\u00f6senordet f\u00f6r klientapplikationen och anv\u00e4nds f\u00f6r att autentisera klientapplikationen mot IdentityServer4<\/code>. Klienthemligheten ska endast vara k\u00e4nd f\u00f6r applikationen och API:et<\/strong>. Utifr\u00e5n det vi just har sagt kan vi dra slutsatsen att IdentityServer4 m\u00e5ste k\u00e4nna till sina klienter<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Om applikationens \u00e4kthet bekr\u00e4ftas och beh\u00f6righeten att auktorisera \u00e4r giltig, IdentiryServer4<\/code> skapar access-token<\/code> (\u00e5tkomsttoken) f\u00f6r applikationen och en valfri uppdateringsnyckel (refresh-token<\/code>). Auktoriseringsprocessen \u00e4r avslutad. Om beg\u00e4ran \u00e4r ogiltig eller oauktoriserad returnerar auktoriseringsservern en kod med ett motsvarande felmeddelande.<\/p>\n

    \n<\/li>\n

  5. \n

    Klientapplikationen beg\u00e4r data fr\u00e5n det skyddade Web API:t, och tillhandah\u00e5ller en \u00e5tkomsttoken f\u00f6r auktorisering. Om serverns svarskod 401<\/a><\/noindex>, 403<\/a><\/noindex> eller 498<\/a><\/noindex>, \u00e4r \u00e5tkomsttoken som anv\u00e4nds f\u00f6r autentisering ogiltig eller har g\u00e5tt ut.<\/p>\n

    \n<\/li>\n

  6. \n

    Om token \u00e4r giltig, Web API<\/code> tillhandah\u00e5ller den data till applikationen.<\/p>\n

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

    <\/p>\n

    Typer av token<\/em><\/h4>\n

    <\/p>\n

    Registrerade IdentityServer4<\/code> klienter f\u00e5r beg\u00e4ra IdentityServer4<\/code> identity<\/code>-token, access<\/code>-token och refresh<\/code>-token.<\/p>\n

    <\/p>\n