🥇IdentityServer4. Grundläggande begrepp. OpenID Connect, OAuth 2.0 och JWT

Med detta inlägg vill jag starta en serie artiklar som handlar om IdentityServer4. Vi börjar med de grundläggande begreppen.

Den mest lovande autentiseringsprotokollet just nu är OpenID Connect, medan auktoriseringsprotokollet (åtkomstbeviljande) är OAuth 2.0. IdentityServer4 implementerar dessa två protokoll. Det är optimerat för att lösa typiska säkerhetsproblem. säkerhet.

OpenID Connect — det är ett autentiseringsprotokoll och standard, det ger inte tillgång till resurser (Web API), men eftersom det är utvecklat ovanpå auktoriseringsprotokollet OAuth 2.0, låter det dig hämta användarprofilens parametrar som om du fick tillgång till resursen UserInfo.
JWT (JSON Web Token) är en webstandard som definierar hur användardata kan överföras i JSON-format på ett säkert sätt.
OAuth 2.0 (RFC 6749) — det är ett auktoriseringsprotokoll och standard. Det tillåter applikationer att få tillgång till skyddade resurser, till exempel Web API.

Låt oss titta på diagrammet för att få åtkomst till en skyddad resurs och gå igenom de grundläggande stegen och den accepterade terminologin:

Klienten begär tillstånd av användaren att genomgå autentisering å hans eller hennes vägnar. Klient — det är en klientapplikation som begär åtkomst till skyddade resurser å ägarens vägnar. Resurs — det är alla våra skyddade tjänster Web API.
Användaren tillåter klientapplikationen att genomgå autentisering å hans eller hennes vägnar, till exempel genom att ange användarnamn och lösenord. Användarnamn och lösenord kommer att fungera som ett auktoriseringstillstånd för klientapplikationen. Användare (resursägaren) — ett program eller en person som kan ge åtkomst till skyddade resurser, till exempel genom att ange användarnamn (username) och lösenord (password);
Klientapplikationen begär en åtkomsttoken från IdentityServer4 genom att tillhandahålla information om sig själv (client_id, client_secret), tillhandahålla tillstånd för autentisering från användaren (username, password) och tillhandahålla grant_type och scope. Sedan verifierar auktoriseringsservern klientens äkthet och resurshavaren (användarnamn och lösenord).
OAuth 2.0-protokollet autentiserar inte bara användaren, utan även klientapplikationen som får åtkomst till resurser. För detta ändamål föreskriver protokollet parametrar som client_id och client_secret.
client_id — det är identifieraren för klientapplikationen, som används IdentityServer4 för att hämta information om klienten.
client_secret är en motsvarighet till lösenordet för klientapplikationen och används för att autentisera klientapplikationen mot IdentityServer4. Klienthemligheten ska endast vara känd för applikationen och API:et. Utifrån det vi just har sagt kan vi dra slutsatsen att IdentityServer4 måste känna till sina klienter.
Om applikationens äkthet bekräftas och behörigheten att auktorisera är giltig, IdentiryServer4 skapar access-token (åtkomsttoken) för applikationen och en valfri uppdateringsnyckel (refresh-token). Auktoriseringsprocessen är avslutad. Om begäran är ogiltig eller oauktoriserad returnerar auktoriseringsservern en kod med ett motsvarande felmeddelande.
Klientapplikationen begär data från det skyddade Web API:t, och tillhandahåller en åtkomsttoken för auktorisering. Om serverns svarskod 401, 403 eller 498, är åtkomsttoken som används för autentisering ogiltig eller har gått ut.
Om token är giltig, Web API tillhandahåller den data till applikationen.

Typer av token

Registrerade IdentityServer4 klienter får begära IdentityServer4 identity-token, access-token och refresh-token.

identity-token (identitetstoken) — resultatet av autentiseringsprocessen. Innehåller användarens identifierare och information om hur och när användaren autentiserades. Kan utvidgas med egna data.
access-token (åtkomsttoken) — överförs till det skyddade API:t och används av det för att åta sig (ge tillgång till) sina data.
refresh-token (uppdateringstoken) — en valfri parameter som auktoriseringsservern kan returnera som svar på begäran om åtkomsttoken.

Låt oss introducera ytterligare två begrepp:

Authenticatation Server Url — slutpunkt för att få åtkomstnyckeln. Alla begärningar om att utfärda och förlänga åtkomstnycklar kommer att riktas till denna URL.

Resource Url — URL-adress till den skyddade resursen som man måste nå för att få tillgång till den, genom att skicka med åtkomstnyckeln i auktoriseringshuvudet.

Begäran om åtkomstnyckel

För att begära åtkomstnyckeln gör klienten POST begäran till slutpunkten IdentityServer4 med följande huvuden

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

och skickar följande parametrar:

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

username, password, client_id och client_secret har redogjorts för ovan. Låt oss gå igenom de övriga parametrarna:

grant_type — granttyp eller behörighetstyp. Behörighetstypen beror på den metod som används av applikationen för att begära autentisering samt vilka typer av behörigheter som stöds av API:et. I vårt fall kommer det att ha värdet password, vilket enligt specifikationen OAuth 2.0 motsvarar grant-type för behörighetsuppgifter från resursägaren (autentisering med användarnamn och lösenord).

Protokoll OAuth 2.0 definierar följande typer av grants som kräver obligatorisk interaktion med användarna:

autentiseringskod (authorization code). Är en av de vanligaste typerna av autentisering, eftersom den passar bra för serverbaserade applikationer (server-side applications), där applikationens källkod och klienthemlighet inte är tillgängliga för utomstående;
implicit. Den implicita typen av autentisering används av mobila och webbapplikationer, där sekretessen för klienthemligheten inte kan garanteras;

Och typerna av grants som kan utföras utan interaktivt samspel med användarna:

resursägaren.. Denna typ av autentisering bör endast användas när klientapplikationen har användarens förtroende och användaren är bekväm med att ange sitt användarnamn och lösenord. Denna typ av autentisering bör endast användas när andra alternativ inte är tillgängliga. Denna typ av autentisering är praktisk för företagskunder som redan har använt användarens uppgifter i sitt system och vill gå över till OAuth 2.0.
klientuppgifter.. Används vid applikationens åtkomst till API:et. Detta kan vara användbart när applikationen vill uppdatera sin egen registreringsinformation på tjänsten eller URI:n för omdirigering, eller få åtkomst till annan information som lagras i applikationens konto på tjänsten via API:et.

scope — det är en valfri parameter. Den definierar omfattningen. Åtkomsttoken som returneras av servern ger endast åtkomst till de tjänster som ingår i denna omfattning. Det vill säga, vi kan kombinera flera tjänster under en och samma scope, och om klienten får en åtkomstnyckel till denna scope får den åtkomst till alla dessa tjänster. Omfattning kan också användas för att begränsa behörigheter (till exempel läs- eller skrivåtkomst)

Källa: habr.com