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

Med dette indl\u00e6g vil jeg \u00e5bne en r\u00e6kke artikler dedikeret til IdentityServer4. Lad os begynde med de grundl\u00e6ggende begreber.<\/p>\n

<\/p>\n

Den mest lovende autentifikationsprotokol p\u00e5 nuv\u00e6rende tidspunkt er OpenID Connect<\/a><\/noindex>, og autorisationsprotokollen (adgangsgivende) er OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> som implementerer disse to protokoller. Den er optimeret til at l\u00f8se typiske sikkerhedsproblemer.<\/strong> sikkerhed.<\/p>\n

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

OpenID Connect<\/a><\/noindex> \u2014 det er en protokol og standard for autentifikation, den giver ikke adgang til ressourcer (Web API), men da den er udviklet oven p\u00e5 autorisationsprotokollen, OAuth 2.0<\/a><\/noindex>giver den mulighed for at f\u00e5 brugerprofilparametre, som om du havde f\u00e5et adgang til ressourcen UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) repr\u00e6senterer en webstandard, der definerer m\u00e5den at overf\u00f8re brugerdata i JSON-format p\u00e5 i krypteret form.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 det er en protokol og standard for autorisation. Den giver applikationer adgang til beskyttede ressourcer, s\u00e5som Web API.<\/p><\/blockquote>\n

Lad os tage et kig p\u00e5 diagrammet for adgang til en beskyttet ressource og forst\u00e5 de grundl\u00e6ggende trin og den accepterede terminologi:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Klienten beder brugeren om tilladelse til at gennemg\u00e5 autorisation p\u00e5 hans vegne. Kunde<\/strong> \u2014 det er en klientapplikation, der henvender sig til beskyttede ressourcer p\u00e5 vegne af ejer af ressourcerne. Platformen<\/strong> \u2014 det er alle vores beskyttede tjenester Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    Brugeren tillader klientapplikationen at gennemg\u00e5 autorisation p\u00e5 hans vegne, for eksempel ved at indtaste brugernavn og password. Brugernavnet og passwordet vil fungere som autorisationstilladelse for klientapplikationen. Bruger (ejer af ressourcen)<\/strong> \u2014 programmet eller personen, der kan give adgang til beskyttede ressourcer, for eksempel ved at indtaste brugernavn (username) og password (password);<\/p>\n

    \n<\/li>\n

  3. \n

    Klientapplikationen anmoder om en adgangstoken hos IdentityServer4<\/code> ved at give oplysninger om sig selv (client_id<\/code>, client_secret<\/code>), give tilladelse til autorisation fra brugeren (brugernavn<\/code>, adgangskode<\/code>) og give grant_type<\/code> og scope<\/code>. Derefter kontrollerer autorisationsserveren klientens legitimationsoplysninger og ejerens ressourcers legitimationsoplysninger (brugernavn og password). <\/p>\n

    <\/p>\n

    OAuth 2.0 protokollen udf\u00f8rer autentifikation ikke kun af brugeren, men ogs\u00e5 af klientapplikationen, der f\u00e5r adgang til ressourcerne. Til dette form\u00e5l forudser protokollen parametre som client_id<\/strong> og client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 det er identifikatoren for klientapplikationen, der anvendes IdentityServer4<\/code> til at finde oplysninger om klienten.
    \nclient_secret<\/strong> er en analog til adgangskoden for klientapplikationen og anvendes til autentificering af klientapplikationen p\u00e5 IdentityServer4<\/code>. Klienthemmeligheden skal kun v\u00e6re kendt af applikationen og API'et<\/strong>. Baseret p\u00e5 det ovenst\u00e5ende konkluderer vi, at IdentityServer4 skal v\u00e6re bekendt med sine kunder<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Hvis applikationens legitimitet er bekr\u00e6ftet, og autorisationstilladelsen er gyldig, IdentiryServer4<\/code> opretter access-token<\/code> (adgangstoken) til applikationen og en valgfri refresh-token (refresh-token<\/code>). Autorisationsprocessen er afsluttet. Hvis anmodningen er ugyldig eller uautoriseret, returnerer autorisationsserveren en kode med den relevante fejlmeddelelse.<\/p>\n

    \n<\/li>\n

  5. \n

    Klientapplikationen anmoder om data fra det beskyttede Web API, idet den giver adgangstokenet til autorisation. Hvis serverens ressourcedekodning, 401<\/a><\/noindex>, 403<\/a><\/noindex> eller 498<\/a><\/noindex>, s\u00e5 er adgangstokenet, der anvendes til autentificering, ugyldigt eller udl\u00f8bet.<\/p>\n

    \n<\/li>\n

  6. \n

    Hvis token er gyldigt, Web API<\/code> giver det data til applikationen.<\/p>\n

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

    <\/p>\n

    Typer af tokens<\/em><\/h4>\n

    <\/p>\n

    Registrerede IdentityServer4<\/code> kunder kan anmode om IdentityServer4<\/code> identity<\/code>-token, access<\/code>-token og refresh<\/code>-token.<\/p>\n

    <\/p>\n