Illustrerad guide till OAuth och OpenID Connect

Obs. övers.: I detta fantastiska material från företaget Okta förklaras på ett enkelt och tydligt sätt hur OAuth och OIDC (OpenID Connect) fungerar. Dessa kunskaper kommer att vara användbara för utvecklare, systemadministratörer och även "vanliga användare" av populära webbapplikationer, som sannolikt också delar känslig information med andra tjänster.

I "stenåldern" av internet var det enkelt att dela information mellan tjänster. Du gav bara ditt användarnamn och lösenord från en tjänst till en annan så att den kunde logga in på ditt konto och hämta all information den behövde.

"Ge oss dina bankuppgifter." — "Vi lovar att allt kommer att vara okej med ditt lösenord och dina pengar. Ärligt talat!" *fniss*

Gärna! Ingen bör någonsin begära att en användare ska dela sitt användarnamn och lösenord, sina inloggningsuppgifter, med en annan tjänst. Det finns ingen garanti för att organisationen bakom denna tjänst kommer att lagra uppgifterna säkert och inte samla in mer personlig information än nödvändigt. Det kan verka galet, men vissa applikationer tillämpar fortfarande denna praxis!

Idag finns det en enhetlig standard som gör det möjligt för en tjänst att säkert använda data från en annan. Tyvärr använder sådana standarder massor av jargong och termer, vilket gör dem svåra att förstå. Syftet med detta material är att, med hjälp av enkla bilder, förklara hur de fungerar (Tycker du mina bilder liknar barnslig klotter? Jaha då!).

För övrigt finns denna vägledning också tillgänglig i videoformat:

Mina damer och herrar, här är: OAuth 2.0

OAuth 2.0 — en säkerhetsstandard som möjliggör för en applikation att få tillstånd att få åtkomst till information i en annan applikation. Sekvensen av åtgärder för att ge tillstånd [permission] (eller samtycke [consent]) kallas ofta auktorization [authorization] eller till och med delegerad auktorisation [delegated authorization]. Med hjälp av denna standard tillåter du en applikation att läsa data eller använda funktioner från en annan applikation i ditt namn utan att ge den ditt lösenord. Klart!

Som exempel, tänk dig att du upptäckte en webbplats med namnet "Dagens hemska ordvits" [Terrible Pun of the Day] och bestämde er för att registrera er där för att dagligen få kalas-skämt som textmeddelanden på telefonen. Ni gillade verkligen webbplatsen och bestämde er för att dela den med alla bekanta. Förskräckliga kalas-skämt är ju något alla gillar, eller hur?

«Dagens misslyckade skämt: Har ni hört om killen som förlorade vänstra halvan av sin kropp? Nu har han alltid rätt!» (översättningen är ungefärlig, eftersom det finns ett eget ordspel i originalet — anm. övers.)

Det är uppenbart att det inte är ett alternativ att skriva till varje person från kontaktlistan. Och om ni är åtminstone lite lik mig, kommer ni att göra vad som helst för att undvika extra arbete. Lyckligtvis kan Terrible Pun of the Day själv bjuda in alla era vänner! Ni behöver bara ge den tillgång till e-postkontakterna — webbplatsen skickar automatiskt inbjudningar till dem (OAuth är fantastiskt)!

«Alla älskar skämt! — Har ni redan loggat in? — Vill ni ge Terrible Pun of the Day tillgång till er kontaktlista? — Tack! Nu kommer vi att skicka påminnelser varje dag till alla ni känner, till tidens ände! Ni är den bästa vännen!»

1. Välj er e-posttjänst.
2. Om så behövs, gå till e-postsidan och logga in på kontot.
3. Ge Terrible Pun of the Day tillstånd att få tillgång till kontakterna.
4. Gå tillbaka till webbplatsen Terrible Pun of the Day.

Om ni ändrar er, erbjuder appar som använder OAuth också ett sätt att återkalla åtkomst. Om ni bestämmer er för att ni inte längre vill dela kontakterna med Terrible Pun of the Day, kan ni gå till e-postsidan och ta bort webbplatsen för skämt från listan över auktoriserade appar.

OAuth-flöde

Vi har just gått igenom vad som vanligen kallas ett flöde [flow] 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 en säker informationsutbyte. I det tidigare exemplet med Terrible Pun of the Day används den mest förekommande OAuth 2.0-flödet, känt som flödet "med auktoriseringskod". [«authorization code» flow].

Innan vi dyker djupare in i hur OAuth fungerar, låt oss prata om betydelsen av vissa termer:

• Resursägare:

  
  
  Det är ni! Ni äger era inloggningsuppgifter, era data och kontrollerar alla åtgärder som kan utföras med era konton.

• Client:

  
  
  En applikation (t.ex. tjänsten Terrible Pun of the Day) som vill få åtkomst eller utföra vissa åtgärder å Resursägare’s vägnar.

• Auktoriseringsserver:

  
  
  En applikation som vet Resursägare’s och där Resursägare’s redan har ett konto.

• Resurserver:

  
  
  Ett programgränssnitt (API) eller tjänst som Client vill använda å Resursägare’s vägnar.

• Omdirigerings-URI:

  
  
  Länken som Auktoriseringsserver omdirigerar Resursägare’s efter att ha gett tillstånd Clienttill. Ibland kallas den "Återvändande URL" ("Callback URL").

• Svarstyp:

  
  
  Typ av information som förväntas fås Client. Den vanligaste Svarstyp’n är en kod, det vill säga Client räknar med att få Auktoriseringskod.

• Omfång:

  
  
  Detta är en detaljerad beskrivning av de behörigheter som krävs av Client’s, såsom åtkomst till data eller utförande av specifika åtgärder.

• Samtycke:

  
  
  Auktoriseringsserver tar Omfång, begärd av Client’s, och frågar Resursägare’s om denne är villig att ge Client’s motsvarande behörigheter.

• Klient-ID:

  
  
  Detta ID används för att identifiera Client’s på Auktoriseringsserver’s.

• Klienthemlighet:

  
  
  Detta är ett lösenord som endast är känt av Client’s och Auktoriseringsserver’s. Det möjliggör att de konfidentiellt kan dela information.

• Auktoriseringskod:

  
  
  En tillfällig kod med en kort tidsperiod som Client skydd mot DDoS-attacker Auktoriseringsserver’s i utbyte mot Åtkomsttoken.

• Åtkomsttoken:

  
  
  En nyckel som klienten kommer att använda för att kommunicera med Resurserver’s. En typ av tagg eller nyckelkort som ger Client’s behörighet att begära data eller utföra åtgärder på Resurserver’s å dina vägnar.

Anmärkning: ibland är auktoriseringsserver och resurserver samma server. Men i vissa fall kan de vara olika servrar, även om de inte tillhör samma organisation. Till exempel kan auktoriseringsservern vara en tredjepartstjänst som resurservern har förtroende för.

Nu när vi har bekantat oss med de grundläggande begreppen i OAuth 2.0, låt oss gå tillbaka till vårt exempel och noggrant titta på vad som händer i OAuth-flödet.

1. Du, Resursägare, önskar att ge tjänsten Terrible Pun of the Day (Client’s) åtkomst till dina kontakter så att den kan skicka inbjudningar till alla dina vänner.
2. Client omdirigerar webbläsaren till sidan Auktoriseringsserver’s och inkluderar i förfrågan Klient-ID, Omdirigerings-URI, Svarstyp och en eller flera Omfång (behörigheter) som den behöver.
3. Auktoriseringsserver verifierar dig, och ber vid behov om användarnamn och lösenord.
4. Auktoriseringsserver visar ett formulär Samtycke (bekräftelse) med en lista över alla Omfång, begärd av Client’s. Du godkänner eller nekar.
5. Auktoriseringsserver omdirigerar dig till webbplatsen Client’s, med användning av Omdirigerings-URI tillsammans med Auktoriseringskod (auktoriseringskoden).
6. Client kommunicerar direkt med Auktoriseringsserver’s (via webbläsaren) Resursägare‘a) och säkert skickar Klient-ID, Klienthemlighet och Auktoriseringskod.
7. Auktoriseringsserver kontrollerar data och svarar med Åtkomsttoken‘en (åtkomsttoken).
8. Nu Client kan använda Åtkomsttoken för att skicka en begäran om Resurserver med syfte att få en lista över kontakter.

Client ID och Secret

Långt innan du gav Terrible Pun of the Day tillgång till kontakterna, hade Client och Authorization Server etablerat ett samarbete. Authorization Server genererade Client ID och Client Secret (ibland kallade App ID och App Secret) och skickade dem till Client för vidare interaktion inom ramen för OAuth.

«— Hej! Jag skulle vilja arbeta med dig! — Ingen fara! Här är dina Client ID och Secret!»

Namnet antyder att Client Secret bör hållas hemligt, så att endast Client och Authorization Server känner till det. Det är ju med hjälp av det som Authorization Server bekräftar äktheten av Client.

Men det är inte allt… Vänligen välkomna OpenID Connect!

OAuth 2.0 har utvecklats enbart för autentisering — för att ge åtkomst 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 information om inloggning och profilen för den användare som har loggat in. Organisationen av inloggningssessioner kallas ofta för autentisering [authentication], medan information om användaren som loggade in (dvs. om Resursägare‘n), — personuppgifter [identity]. Om Authorization Server stöder OIDC kallas den ibland för identitetsleverantör [identity provider], eftersom den tillhandahåller Client‘n information om Resursägare’s.

OpenID Connect gör det möjligt att implementera scenarier där en enda inloggning kan användas i flera applikationer — denna metod är också känd som single sign-on (SSO). Till exempel kan en applikation stödja SSO-integration med sociala nätverk som Facebook eller Twitter, vilket möjliggör för användarna att använda ett konto som de redan har och som de föredrar att använda.

Flödet (flow) för OpenID Connect ser likadant ut som i fallet med OAuth. Den enda skillnaden är att i den första begäran är den specifika scope som används — openid, — och Client i slutändan får som Åtkomsttoken, såväl som ID Token..

Precis som i OAuth-flödet är Åtkomsttoken i OpenID Connect — detta är ett värde som inte är begripligt Client‘n. Utifrån Client‘n Åtkomsttoken representerar en sträng av tecken som skickas med varje begäran till Resurserver‘n, och den avgör om token är giltig. ID Token. representerar något helt annat.

ID Token är en JWT

ID Token. — det är en specifikt formaterad sträng av tecken, känd som JSON Web Token eller JWT. (ibland uttalas JWT som «jots»). För utomstående observatörer kan JWT verka som en obegriplig samling ord, men Client kan extrahera olika informationer från JWT, såsom ID, användarnamn, inloggningstid, utgångstid ID Token.och eventuella försök till intrång i JWT. Data inuti ID Token.kallas påståenden [claims].

Vid OIDC finns det också en standardmetod genom vilken Client man kan begära mer information om identiteten [identity] från Auktoriseringsservertill exempel e-postadress, med hjälp av Åtkomsttoken.

Ytterligare information om OAuth och OIDC

Så vi har kortfattat gått igenom grunderna för OAuth och OIDC. Redo att dyka djupare? Här är fler resurser som hjälper dig att lära dig mer om OAuth 2.0 och OpenID Connect:

• Vad är OAuth?
• Ingen bryr sig om OAuth eller OpenID Connect
• Implementera OAuth 2.0 Auktoriseringskod med PKCE-flöde
• Vad är OAuth 2.0 Beviljningstyp?
• OAuth 2.0 Från kommandoraden
• Bygg en säker Node.js-app med SQL Server

Som alltid, tveka inte att kommentera. För att hålla dig uppdaterad om våra senaste nyheter, följ Twitter och YouTube Okta för utvecklare!

P.S. från översättaren

Läs även i vår blogg:

• «Säkerhetsalfabetet i Kubernetes: autentisering, auktorisering, granskning»;
• «Användare och RBAC-auktorisering i Kubernetes»;
• «33+ verktyg för Kubernetes-säkerhet»;
• «Säkerhet för Docker-containrar».

Källa: habr.com