IdentityServer4. Grundlæggende begreber. OpenID Connect, OAuth 2.0 og JWT

Med dette indlæg vil jeg åbne en række artikler dedikeret til IdentityServer4. Lad os begynde med de grundlæggende begreber.

Den mest lovende autentifikationsprotokol på nuværende tidspunkt er OpenID Connect, og autorisationsprotokollen (adgangsgivende) er OAuth 2.0. IdentityServer4 som implementerer disse to protokoller. Den er optimeret til at løse typiske sikkerhedsproblemer. безопасности.

OpenID Connect — det er en protokol og standard for autentifikation, den giver ikke adgang til ressourcer (Web API), men da den er udviklet oven på autorisationsprotokollen, OAuth 2.0giver den mulighed for at få brugerprofilparametre, som om du havde fået adgang til ressourcen UserInfo.

JWT (JSON Web Token) repræsenterer en webstandard, der definerer måden at overføre brugerdata i JSON-format på i krypteret form.

OAuth 2.0 (RFC 6749) — det er en protokol og standard for autorisation. Den giver applikationer adgang til beskyttede ressourcer, såsom Web API.

Lad os tage et kig på diagrammet for adgang til en beskyttet ressource og forstå de grundlæggende trin og den accepterede terminologi:

1. Klienten beder brugeren om tilladelse til at gennemgå autorisation på hans vegne. Kunde — det er en klientapplikation, der henvender sig til beskyttede ressourcer på vegne af ejer af ressourcerne. Platformen — det er alle vores beskyttede tjenester Web API.

2. Brugeren tillader klientapplikationen at gennemgå autorisation på hans vegne, for eksempel ved at indtaste brugernavn og password. Brugernavnet og passwordet vil fungere som autorisationstilladelse for klientapplikationen. Bruger (ejer af ressourcen) — programmet eller personen, der kan give adgang til beskyttede ressourcer, for eksempel ved at indtaste brugernavn (username) og password (password);

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

   OAuth 2.0 protokollen udfører autentifikation ikke kun af brugeren, men også af klientapplikationen, der får adgang til ressourcerne. Til dette formål forudser protokollen parametre som client_id og client_secret.
   client_id — det er identifikatoren for klientapplikationen, der anvendes IdentityServer4 til at finde oplysninger om klienten.
   client_secret er en analog til adgangskoden for klientapplikationen og anvendes til autentificering af klientapplikationen på IdentityServer4. Klienthemmeligheden skal kun være kendt af applikationen og API'et. Baseret på det ovenstående konkluderer vi, at IdentityServer4 skal være bekendt med sine kunder.

4. Hvis applikationens legitimitet er bekræftet, og autorisationstilladelsen er gyldig, IdentiryServer4 opretter access-token (adgangstoken) til applikationen og en valgfri refresh-token (refresh-token). Autorisationsprocessen er afsluttet. Hvis anmodningen er ugyldig eller uautoriseret, returnerer autorisationsserveren en kode med den relevante fejlmeddelelse.

5. Klientapplikationen anmoder om data fra det beskyttede Web API, idet den giver adgangstokenet til autorisation. Hvis serverens ressourcedekodning, 401, 403 eller 498, så er adgangstokenet, der anvendes til autentificering, ugyldigt eller udløbet.

6. Hvis token er gyldigt, Web API giver det data til applikationen.

Typer af tokens

Registrerede IdentityServer4 kunder kan anmode om IdentityServer4 identity-token, access-token og refresh-token.

• identity-token (identitetstoken) — resultatet af autentificeringsprocessen. Det indeholder bruger-ID'et og information om, hvordan og hvornår brugeren blev autentificeret. Det kan udvides med egne data.
• access-token (adgangstoken) — sendes til det beskyttede API og bruges af det til at autorisere (give adgang) til sine data.
• refresh-token (opdateringstoken) — et valgfrit parameter, som autorisationsserveren kan returnere som svar på en anmodning om adgangstoken.

Lad os introducere to yderligere begreber:

Authenticatation Server Url — slutpunktet for at modtage adgangsnøglen. Alle anmodninger om tildeling og fornyelse af adgangsnøgler vil blive sendt til denne URL.

Resource Url — URL'en for den beskyttede ressource, man skal kontakte for at få adgang til den, ved at sende adgangsnøglen i autorisationsheaderen.

Anmodning om adgangsnøgle

For at anmode om en adgangsnøgle foretager klienten POST anmodning til slutpunktet IdentityServer4 med følgende header

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

og sender de følgende parametre:

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

brugernavn, adgangskode, client_id og client_secret blev diskuteret ovenfor. Lad os gennemgå de øvrige parametre:

grant_type — grant type or authorization grant type. The authorization grant type depends on the method used by the application for the authorization request, as well as what types of grants are supported by the API. In our case, it will be set to adgangskode, which according to the specification OAuth 2.0 corresponds to the resource owner's credentials grant (authorization by username and password).

Protokol OAuth 2.0 defines the following types of grants that require mandatory interaction with users:

• authorization code. It is one of the most common types of authorization grants, as it is well-suited for server-side applications, where the application's source code and client secret are not available to outsiders;
• implicit. The implicit authorization grant type is used by mobile and web applications where the confidentiality of the client secret cannot be guaranteed;

And the types of grants that can be executed without interactive user interaction:

• resource owner credentials.This type of authorization should only be used when the client application is trusted by the user and the user is comfortable entering their username and password. This type of grant should only be used when no other options are available. This type of grant is convenient for corporate clients who have already used user credentials within their system and want to switch to OAuth 2.0.
• client credentials.Used when an application accesses the API. This can be useful, for example, when the application wants to update its own registration details on the service or redirect URI, or access other information stored in the application's account on the service through the service's API.

scope — dette er en valgfri parameter. Den definerer synlighedsområdet. Adgangstokenet, der returneres af serveren, vil kun give adgang til de tjenester, der ligger inden for dette område. Dvs. vi kan samle flere tjenester under én scope, og hvis klienten får en adgangsnøgle til denne scope, får han adgang til alle disse tjenester. Scope kan også bruges til at begrænse autorisationsrettigheder (f.eks. læse- eller skrivetilgang)

Kilde: habr.com