🥇IdentityServer4. Basisconcepten. OpenID Connect, OAuth 2.0 en JWT

Met deze post wil ik een reeks artikelen openen over IdentityServer4. We beginnen met de basisconcepten.

Op dit moment is het meest veelbelovende authenticatieprotocol OpenID Connect, terwijl het autorisatieprotocol (toegang verlenen) is OAuth 2.0. IdentityServer4 deze twee protocollen implementeert. Het is geoptimaliseerd voor het oplossen van typische beveiligingsproblemen. Dit is een protocol en standaard voor authenticatie; het biedt geen toegang tot middelen (Web API), maar omdat het is ontwikkeld bovenop het autorisatieprotocol,

OpenID Connect biedt het de mogelijkheid om gebruikersprofielparameters te verkrijgen alsof je toegang hebt gekregen tot de bron. OAuth 2.0UserInfo (JSON Web Token) is een webstandaard die een manier definieert om gebruikersgegevens in JSON-formaat versleuteld te verzenden..
JWT OAuth 2.0 (RFC 6749)
is een protocol en standaard voor autorisatie. Het stelt applicaties in staat toegang te krijgen tot beschermde middelen, zoals Web API. Laten we naar het diagram kijken van het aanvragen van toegang tot een beschermd middel en de belangrijkste stappen en gebruikte terminologie bespreken:

De client vraagt de gebruiker om toestemming om autorisatie aan te vragen namens hem.

Dit is de clientapplicatie die toegang vraagt tot beschermde middelen namens de eigenaar van de middelen. Klant Dit zijn al onze beveiligde diensten. Hulpbron De gebruiker staat de clientapplicatie toe om autorisatie aan te vragen namens hem, bijvoorbeeld door zijn gebruikersnaam en wachtwoord in te voeren. De gebruikersnaam en het wachtwoord zullen de autorisatiegrant zijn voor de clientapplicatie. Web API.
De gebruiker (eigenaar van de middelen) is een programma of persoon die toegang kan verlenen tot beschermde middelen, bijvoorbeeld door een gebruikersnaam (username) en wachtwoord (password) in te voeren; De clientapplicatie vraagt toegangstoken aan bij
door zijn eigen informatie te verstrekken ( IdentityServer4 client_secretclient_id, ), toestemming voor autorisatie van de gebruiker te geven () en het verstrekken vanusername, passwordgrant_type . Vervolgens controleert de autorisatieserver de authenticiteit van de client en de gegevens van de eigenaar van de middelen (gebruikersnaam en wachtwoord). en scopeHet OAuth 2.0-protocol voert authentificatie uit, niet alleen voor de gebruiker, maar ook voor de clientapplicatie die toegang heeft tot de middelen. Hiervoor voorziet het protocol in parameters zoals
client_id client_id en ), toestemming voor autorisatie van de gebruiker te geven (.
dit is de identificatie van de clientapplicatie, gebruikt voor het opzoeken van informatie over de client. IdentityServer4 .
), toestemming voor autorisatie van de gebruiker te geven ( is het equivalent van een wachtwoord voor de clienttoepassing en wordt gebruikt voor de authenticatie van de clienttoepassing op IdentityServer4. De clientsecret moet alleen bekend zijn bij de toepassing en de API. Op basis van het bovenstaande kunnen we concluderen dat IdentityServer4 op de hoogte moet zijn van zijn klanten.
Als de echtheid van de toepassing is bevestigd en de autorisatie is geldig, IdentityServer4 creëert access-token (toegangstoken) voor de toepassing en een optionele vernieuwingssleutel (refresh-token). Het autorisatieproces is voltooid. Als het verzoek ongeldig of ongeautoriseerd is, retourneert de autorisatieserver een code met een bijbehorend foutbericht.
De clienttoepassing vraagt om gegevens van de beveiligde Web API, waarbij het toegangstoken wordt verstrekt voor autorisatie. Als de serverresponscode 401, 403 of 498, is het toegangstoken dat wordt gebruikt voor authenticatie ongeldig of verlopen.
Als het token geldig is, Web API geeft het gegevens aan de toepassing.

Token types

Geregistreerde IdentityServer4 klanten mogen aanvragen bij IdentityServer4 identity-token, access-token en Vernieuw afbeeldingen-token.

identity-token (identificatie-token) — resultaat van het authenticatieproces. Bevat de gebruikersidentificatie en informatie over hoe en wanneer de gebruiker zich authenticeert. Kan met eigen gegevens worden uitgebreid.
access-token (toegangstoken) — wordt overgedragen aan de beveiligde API en door deze gebruikt voor autorisatie (toegangstoestemming) tot zijn gegevens.
refresh-token (vernieuwtoken) — een optionele parameter die de autorisatieserver kan retourneren in reactie op een aanvraag voor een toegangstoken.

Laten we nog twee begrippen introduceren:

Authentication Server URL — het eindpunt voor het verkrijgen van de toegangssleutel. Alle verzoeken voor het verstrekken en vernieuwen van toegangssleutels zullen naar dit URL worden gericht.

Resource URL — het URL-adres van de beveiligde bron waarmee moet worden omgegaan om toegang te krijgen, waarbij de toegangssleutel in de autorisatieheader wordt doorgegeven.

Aanvraag voor toegangssleutel

Voor de aanvraag van de toegangssleutel doet de client PUT een verzoek aan het eindpunt IdentityServer4 met de volgende header

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

en de volgende parameters doorgeeft:

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

username, password, client_id en ), toestemming voor autorisatie van de gebruiker te geven ( waren hierboven besproken. Laten we de overige parameters behandelen:

. Vervolgens controleert de autorisatieserver de authenticiteit van de client en de gegevens van de eigenaar van de middelen (gebruikersnaam en wachtwoord). — type van een grant of type autorisatie. Het type autorisatie hangt af van de door de applicatie gebruikte methode voor het aanvragen van autorisatie, evenals van welke typen autorisatie door de API worden ondersteund. In ons geval zal het de waarde hebben password, wat volgens de specificatie OAuth 2.0 overeenkomt met de grant van toegangselementen van de resource-eigenaar (autorisatie per gebruikersnaam en wachtwoord).

Protocol OAuth 2.0 definieert de volgende soorten grants die vereisen verplichte interactie met gebruikers:

autorisatiecode (authorization code). Dit is een van de meest voorkomende vormen van autorisatie, aangezien het goed geschikt is voor server-side applicaties, waarbij de broncode van de applicatie en de clientsecret niet toegankelijk zijn voor derden;
impliciet (implicit). Het impliciete type autorisatie wordt gebruikt door mobiele en webapplicaties, waarbij de vertrouwelijkheid van de clientsecret niet kan worden gegarandeerd;

En de types grants die kunnen worden uitgevoerd zonder interactieve interactie met gebruikers:

gegevens van de resource-eigenaar (resource owner). Dit type autorisatie moet alleen worden gebruikt wanneer de clientapplicatie het vertrouwen van de gebruiker heeft en de gebruiker zich op zijn gemak voelt om zijn gebruikersnaam en wachtwoord in te voeren. Dit type autorisatie moet alleen worden gebruikt wanneer andere opties niet beschikbaar zijn. Dit type autorisatie is handig voor zakelijke klanten die binnen hun systeem al gebruik hebben gemaakt van de gebruikersreferenties en willen overstappen naar OAuth 2.0.
klantgegevens. Deze worden gebruikt wanneer een applicatie toegang wil krijgen tot de API. Dit kan bijvoorbeeld nuttig zijn wanneer de applicatie haar eigen registratiedetails op de service of de URI voor omleiding wil bijwerken, of toegang wil krijgen tot andere informatie die is opgeslagen in het account van de applicatie op de service via de API van de service.

scope — dit is een optionele parameter. Het definieert de reikwijdte. De toegangstoken, geretourneerd door de server, biedt alleen toegang tot de diensten die binnen deze reikwijdte vallen. Dat wil zeggen, we kunnen meerdere diensten onder één scope samenvoegen en als de klant een toegangscode voor deze scope ontvangt, krijgt hij toegang tot al deze diensten. De scope kan ook worden gebruikt om de machtigingen te beperken (bijvoorbeeld lees- of schrijfrechten).

Bron: habr.com