En illustrerad guide till OAuth och OpenID Connect

Notera. transl.: Denna fantastiska artikel av Okta förklarar hur OAuth och OIDC (OpenID Connect) fungerar på ett enkelt och tydligt sätt. Denna kunskap kommer att vara användbar för utvecklare, systemadministratörer och till och med "vanliga användare" av populära webbapplikationer, som med största sannolikhet också utbyter konfidentiell data med andra tjänster.

Under Internets stenålder var det enkelt att dela information mellan tjänster. Du gav helt enkelt ditt användarnamn och lösenord från en tjänst till en annan, så att han gick in på ditt konto och fick all information han behövde.

"Ge mig ditt bankkonto." ”Vi lovar att allt kommer att bli bra med lösenordet och pengarna. Det är ärligt, ärligt!" *hihi*

Skräck! Ingen ska någonsin kräva att en användare delar ett användarnamn och lösenord, referenser, med en annan tjänst. Det finns ingen garanti för att organisationen bakom denna tjänst kommer att hålla uppgifterna säkra och inte kommer att samla in mer personlig information än nödvändigt. Det kan låta galet, men vissa appar använder fortfarande denna praxis!

Idag finns det en enda standard som tillåter en tjänst att säkert använda data från en annan. Tyvärr använder sådana standarder mycket jargong och termer, vilket komplicerar deras förståelse. Syftet med det här materialet är att förklara hur de fungerar med hjälp av enkla illustrationer (Tycker du att mina teckningar påminner om barns daubing? Nåväl!).

Förresten, den här guiden är också tillgänglig i videoformat:

Mina damer och herrar, välkomna: OAuth 2.0

OAuth 2.0 är en säkerhetsstandard som tillåter en applikation att få tillstånd att komma åt information i en annan applikation. Stegföljd för att utfärda tillstånd [lov] (eller samtycke [samtycke]) ringer ofta tillstånd [tillstånd] eller delegerat tillstånd [delegerad auktorisation]. Med denna standard tillåter du en applikation att läsa data eller använda funktionerna i en annan applikation för din räkning utan att ge den ditt lösenord. Klass!

Som ett exempel, låt oss säga att du upptäcker en webbplats som heter "Dagens oturliga ordlek" [Dagens fruktansvärda ordlek] och bestämde sig för att registrera sig på det för att få dagliga ordlekar i form av textmeddelanden på telefonen. Du gillade verkligen sidan och du bestämde dig för att dela den med alla dina vänner. Alla gillar ju läskiga ordlekar, eller hur?

"Dagens olyckliga ordlek: Hört om killen som tappade den vänstra halvan av sin kropp? Nu har han alltid rätt!” (ungefärlig översättning, eftersom originalet har sin egen ordlek - ungefärlig översättning)

Det är tydligt att det inte är ett alternativ att skriva till varje person från kontaktlistan. Och om du till och med är lite som jag, då kommer du att gå hur långt som helst för att undvika onödigt arbete. Lyckligtvis kan Terrible Pun of the Day bjuda in alla dina vänner på egen hand! För att göra detta behöver du bara öppna åtkomsten till dina kontakters e-post - webbplatsen själv skickar inbjudningar till dem (OAuth-regler)!

"Alla älskar ordlekar! - Redan inloggad? "Vill du tillåta webbplatsen Terrible Pun of the Day att komma åt din kontaktlista? - Tack! Från och med nu kommer vi att skicka påminnelser varje dag till alla du känner, fram till tidens slut! Du är den bästa vännen!"

1. Välj din e-posttjänst.
2. Om det behövs, gå till e-postsidan och logga in på ditt konto.
3. Ge Dagens Terrible Pun tillstånd att komma åt dina kontakter.
4. Återgå till webbplatsen Terrible Pun of the Day.

Om du ändrar dig, erbjuder applikationer som använder OAuth också ett sätt att återkalla åtkomst. När du bestämmer dig för att du inte längre vill dela kontakter med Dagens Terrible Pun, kan du gå till e-postsidan och ta bort ordlekssidan från listan över auktoriserade applikationer.

OAuth-flöde

Vi har precis gått igenom det som brukar kallas flöde [flöde] OAuth. I vårt exempel består detta flöde av synliga steg, samt flera osynliga steg, där två tjänster kommer överens om ett säkert utbyte av information. Det föregående exemplet med Dagens fruktansvärda ordlek använder det vanligaste OAuth 2.0-flödet, känt som "auktoriseringskod"-flödet. ["auktoriseringskod" flöde].

Innan vi går in i detaljerna om hur OAuth fungerar, låt oss prata om innebörden av några termer:

• Resursägare:

  
  
  Det är du! Du äger dina referenser, dina data och kontrollerar alla aktiviteter som kan utföras på dina konton.

• Klient:

  
  
  En applikation (till exempel tjänsten Terrible Pun of the Day) som vill komma åt eller utföra vissa åtgärder på uppdrag av Resursägare'а.

• Auktoriseringsserver:

  
  
  Appen som vet Resursägare'a och i vilken u Resursägare'a har redan ett konto.

• Resursserver:

  
  
  Application Programming Interface (API) eller tjänst som Klient vill använda för räkning Resursägare'а.

• Omdirigera URI:

  
  
  Länken som Auktoriseringsserver kommer att omdirigera Resursägare'och efter att ha gett tillstånd Klient'på. Det kallas ibland för "Callback URL".

• Svarstyp:

  
  
  Den typ av information som förväntas tas emot Klient. Den vanligaste Svarstyp'ohm är koden, det vill säga Klient förväntar sig att ta emot Behörighetskod.

• Omfattning:

  
  
  Detta är en detaljerad beskrivning av de behörigheter som krävs Klient'y, som att komma åt data eller utföra vissa åtgärder.

• Samtycke:

  
  
  Auktoriseringsserver basker Scopesbegärda Klient'om, och frågar Resursägare'a, är han redo att ge Klient'har lämpliga behörigheter.

• kund-ID:

  
  
  Detta ID används för att identifiera Klient'a på Auktoriseringsserver'e.

• Klienthemlighet:

  
  
  Detta är lösenordet som bara är känt Klient'du och Auktoriseringsserver'på. Det låter dem dela information privat.

• Behörighetskod:

  
  
  Tillfällig kod med kort giltighetstid, som Klient erbjuder Auktoriseringsserver'y i utbyte mot tillgång Token.

• tillgång Token:

  
  
  Nyckeln som klienten kommer att använda för att kommunicera med Resursserver'om. Ett slags märke eller nyckelkort som ger Klient'ha tillstånd att begära data eller utföra åtgärder på Resursserver'e på dina vägnar.

Notera: Ibland är auktoriseringsserver och resursserver samma server. Men i vissa fall kan det vara olika servrar, även om de inte tillhör samma organisation. Till exempel kan auktoriseringsservern vara en tredjepartstjänst som betros av resursservern.

Nu när vi har täckt kärnkoncepten för OAuth 2.0, låt oss gå tillbaka till vårt exempel och titta närmare på vad som händer i OAuth-flödet.

1. Du, Resursägare, du vill tillhandahålla tjänsten Terrible Pun of the Day (Klienty) tillgång till dina kontakter så att de kan skicka inbjudningar till alla dina vänner.
2. Klient omdirigerar webbläsaren till sidan Auktoriseringsserver'a och inkludera i fråga kund-ID, Omdirigera URI, Svarstyp och en eller flera Scopes (behörigheter) den behöver.
3. Auktoriseringsserver verifierar dig och ber om ett användarnamn och lösenord vid behov.
4. Auktoriseringsserver visar ett formulär Samtycke (bekräftelser) med en lista över alla Scopesbegärda Klient'om. Du samtycker eller vägrar.
5. Auktoriseringsserver omdirigerar dig till webbplatsen Klient'a, använder Omdirigera URI med Behörighetskod (Behörighetskod).
6. Klient kommunicerar direkt med Auktoriseringsserver'ohm (förbigå webbläsaren Resursägare'a) och skickar säkert kund-ID, Klienthemlighet и Behörighetskod.
7. Auktoriseringsserver kontrollerar uppgifterna och svarar med tillgång Token'om (åtkomsttoken).
8. Nu Klient kan använda tillgång Token att skicka en förfrågan till Resursserver för att få en lista med kontakter.

Klient-ID och hemlighet

Långt innan du tillät Dagens fruktansvärda ordlek att komma åt dina kontakter, hade klient- och auktoriseringsservern etablerat en arbetsrelation. Auktoriseringsservern genererade klient-ID och klienthemlighet (kallas ibland app-id и Appens hemlighet) och skickade dem till klienten för ytterligare interaktion inom OAuth.

"- Hallå! Jag skulle vilja jobba med dig! - Javisst, inget problem! Här är ditt klient-ID och hemlighet!”

Namnet antyder att klienthemligheten måste hållas hemlig så att endast klienten och auktoriseringsservern känner till den. Det är trots allt med hans hjälp som auktoriseringsservern bekräftar sanningen om kunden.

Men det är inte allt... Välkommen OpenID Connect!

OAuth 2.0 är endast utformad för tillstånd - att ge tillgång till data och funktioner från en applikation till en annan. OpenID Connect (OIDC) är ett tunt lager ovanpå OAuth 2.0 som lägger till inloggnings- och profildetaljer för användaren som är inloggad på kontot. Organisationen av en inloggningssession kallas ofta autentisering [autentisering], och information om användaren som är inloggad i systemet (dvs Resursägare'e), — personlig information [identitet]. Om auktoriseringsservern stöder OIDC kallas den ibland för leverantör av personuppgifter [identitetsleverantör]eftersom det ger Klient'har information om Resursägare'e.

OpenID Connect låter dig implementera scenarier där en enda inloggning kan användas i flera applikationer - detta tillvägagångssätt är också känt som enda inloggning (SSO). Till exempel kan en applikation stödja SSO-integration med sociala nätverk som Facebook eller Twitter, vilket gör det möjligt för användare att använda ett konto som de redan har och föredrar att använda.

Flödet (flödet) OpenID Connect ser likadant ut som i fallet med OAuth. Den enda skillnaden är att i den primära begäran är det specifika omfång som används openid, - A Klient så småningom blir som tillgång Token, och ID-token.

Precis som i OAuth-flödet, tillgång Token i OpenID Connect är detta ett värde som inte är tydligt Klient'på. Ur synvinkel Klient'а tillgång Token representerar en sträng av tecken som skickas tillsammans med varje begäran till Resursserver'y, som avgör om token är giltig. ID-token representerar en helt annan sak.

ID-token är en JWT

ID-token är en speciellt formaterad teckensträng som kallas JSON Web Token eller JWT (ibland uttalas JWT-tokens som "jots"). För utomstående observatörer kan JWT tyckas vara obegripligt snack, men Klient kan extrahera olika information från JWT, såsom ID, användarnamn, inloggningstid, utgångsdatum ID-token'a, förekomsten av försök att störa JWT. Data inuti ID-token'a kallas applikationer [påståenden].

När det gäller OIDC finns det också ett standardsätt Klient kan begära ytterligare information om den enskilde [identitet] från Auktoriseringsserver'en, till exempel, en e-postadress som använder tillgång Token.

Läs mer om OAuth och OIDC

Så vi granskade kort hur OAuth och OIDC fungerar. Redo att gräva djupare? Här är ytterligare resurser som hjälper dig att lära dig mer om OAuth 2.0 och OpenID Connect:

• Vad fan är OAuth?
• Ingen bryr sig om OAuth eller OpenID Connect
• Implementera OAuth 2.0-auktoriseringskoden med PKCE Flow
• Vad är OAuth 2.0 Grant Type?
• OAuth 2.0 Från kommandoraden
• Bygg en säker Node.js-app med SQL Server

Som alltid, kommentera gärna. För att hålla dig uppdaterad med våra senaste nyheter, prenumerera på Twitter и Youtube Okta för utvecklare!

PS från översättaren

Läs även på vår blogg:

• «ABC för säkerhet i Kubernetes: Autentisering, auktorisering, revision";
• «Användare och auktorisering RBAC i Kubernetes";
• «33+ Kubernetes säkerhetsverktyg";
• «Säkerhet för Docker-containrar".

Källa: will.com