Illustreret guide til OAuth og OpenID Connect

Bem. overs.: I dette fantastiske materiale fra Okta forklares principperne for, hvordan OAuth og OIDC (OpenID Connect) fungerer enkelt og tydeligt. Denne viden vil være nyttig for udviklere, systemadministratorer og endda 'almindelige brugere' af populære webapplikationer, der sandsynligvis også deler følsomme data med andre tjenester.

I internettets 'stenalder' var det nemt at dele information mellem tjenester. Man gav blot ens login og adgangskode fra én tjeneste til en anden, så den kunne logge ind på ens konto og få de oplysninger, den havde brug for.

"Giv os dit bankkonto. " - "Vi lover, at alt med adgangskoden og pengene vil være i orden. Vi er helt ærlige!" *hi-hi*

Skræmmende! Ingen må nogensinde kræve, at brugeren deler sit login og adgangskode, hans kontooplysninger, med en anden tjeneste. Der er ingen garanti for, at organisationen bag denne tjeneste vil opbevare dataene sikkert og ikke indsamle mere personligt information, end nødvendigt. Det kan virke vildt, men nogle apps anvender stadig denne praksis!

I dag er der en fælles standard, der gør det muligt for én tjeneste sikkert at få adgang til data fra en anden. Desværre bruger sådanne standarder en masse jargon og termer, hvilket komplicerer forståelsen af dem. Målet med dette materiale er at forklare, hvordan de virker med enkle illustrationer (Mener du mine tegninger ligner et barns kruseduller? Nå, så må det være!).

For resten er denne guide også tilgængelig i videoformat:

Mine damer og herrer, mød: OAuth 2.0

OAuth 2.0 — er en sikkerhedsstandard, der giver én applikation tilladelse til at få adgang til oplysninger i en anden applikation. Fremgangsmåden for at give tilladelse [permission] (eller samtykke [consent]) kaldes ofte autorisation [authorization] eller endda delegeret autorisation [delegated authorization]. Denne standard gør det muligt for dig at lade en applikation få adgang til data eller bruge funktioner fra en anden applikation i dit navn, uden at du behøver at give den dit password. Cool!

Som eksempel kan vi forestille os, at du har fundet en hjemmeside med titlen "Dagens dårlige ordspil" [Terrible Pun of the Day] og registreret dig på det, for at modtage ordspil som tekstbeskeder på din telefon hver dag. Du har virkelig nydt websitet og besluttet dig for at dele det med alle dine bekendte. For frygtelige ordspil kan alle lide, ikke sandt?

„Dagens uheldige ordspil: Har du hørt om fyren, der mistede den venstre halvdel af sin krop? Nu er han altid højre!” (oversættelsen er omtrentlig, da der i originalen er flere ordspil — bem. overs.)

Det er klart, at det ikke er en mulighed at skrive til hver enkelt person i din kontaktliste. Og hvis du er bare en smule ligesom mig, vil du gøre alt for at undgå unødvendigt arbejde. Heldigvis kan Terrible Pun of the Day selv invitere alle dine venner! Du skal bare give den adgang til din e-mail kontaktliste — siden sender automatisk invitationerne (OAuth styrer)!

„Alle elsker ordspil! — Er du allerede logget ind? — Vil du give Terrible Pun of the Day adgang til din kontaktliste? — Tak! Nu vil vi hver dag sende påmindelser til alle, du kender, indtil verdens ende! Du er den bedste ven!”

1. Vælg din e-mail-service.
2. Hvis nødvendigt, gå til e-mail-websitet og log ind på din konto.
3. Giv Terrible Pun of the Day tilladelse til at få adgang til dine kontakter.
4. Vend tilbage til Terrible Pun of the Day-siden.

Hvis du ombestemmer dig, giver applikationer, der bruger OAuth, også en måde at tilbagekalde adgangen på. Hvis du beslutter, at du ikke længere ønsker at dele dine kontakter med Terrible Pun of the Day, kan du gå til e-mail-websitet og fjerne ordspilssitet fra listen over godkendte applikationer.

OAuth-strømmen

Vi har netop gennemgået, hvad der normalt kaldes strömmen [flow] OAuth. I vores eksempel består denne strøm af synlige trin samt flere usynlige trin, hvor to tjenester indgår en aftale om sikker udveksling af oplysninger. I det forrige eksempel med Terrible Pun of the Day bruges den mest almindelige OAuth 2.0 strøm, der er kendt som 'authorization code' strømmen. [„authorization code” flow].

Før vi dykker ned i detaljerne om, hvordan OAuth fungerer, lad os tale om betydningen af nogle termer:

• Resource Owner:

  
  
  Det er dig! Du ejer dine legitimationsoplysninger, dine data og styrer alle handlinger, der kan udføres med dine konti.

• Client:

  
  
  En applikation (for eksempel tjenesten Terrible Pun of the Day), der ønsker at få adgang eller udføre bestemte handlinger på vegne af Resource Owner‘a.

• Autoriseringsserver:

  
  
  En applikation, der ved Resource Owner‘a og hvor Resource Owner‘a allerede har en konto.

• Ressourceserver:

  
  
  Et programinterface (API) eller en tjeneste, som Client ønsker at bruge på vegne af Resource Owner‘a.

• Redirect URI:

  
  
  Et link, som Autoriseringsserver omdirigerer Resource Owner‘a efter at have givet tilladelse til Client‘u. Nogle gange kaldes dette 'Return URL' ('Callback URL').

• Respons Type:

  
  
  Den type information, som man forventer at modtage Client. Den mest almindelige Respons Type‘a er koden, dvs. Client forventer at modtage Autoriseringskode.

• Omfang:

  
  
  Dette er en detaljeret beskrivelse af de tilladelser, der kræves Client‘u, såsom adgang til data eller udførelse af bestemte handlinger.

• Samtykke:

  
  
  Autoriseringsserver indhenter Omfang, der anmodes om af, og spørger Client‘a, om de er klar til at give Resource Owner‘u de relevante tilladelser. ClientKlient ID

• Denne ID bruges til at identificere:

  
  
  ‘a på Client‘e. AutoriseringsserverKlienthemmelighed

• Dette er et kodeord, som kun er kendt af:

  
  
  ‘u og Client‘u. Det giver dem mulighed for at udveksle information fortroligt. AutoriseringsserverEn midlertidig kode med en kort gyldighedsperiode, som

• Autoriseringskode:

  
  
  ‘u i bytte for Client tilbyder AutoriseringsserverAdgangstoken En nøgle, som klienten vil bruge til at kommunikere med.

• En nøgle, som klienten vil bruge til at kommunikere med:

  
  
  ‘om. En slags badge eller nøglekort, der giver Ressourceserver‘u tilladelse til at anmode om data eller udføre handlinger på Client‘e på dine vegne. Ressourceserver: nogle gange er Autoriseringsserveren og Ressourceserveren den samme server. Men i nogle tilfælde kan de være forskellige servere, som ikke nødvendigvis tilhører den samme organisation. For eksempel kan Autoriseringsserveren være en tredjepartstjeneste, som Ressourceserveren har tillid til.

BemærkNu hvor vi har sat os ind i de grundlæggende begreber i OAuth 2.0, lad os vende tilbage til vores eksempel og se nærmere på, hvad der sker i OAuth-strømmen.

Du,

1. , ønsker at give tjenesten Terrible Pun of the Day ( Resource Owner‘u) adgang til dine kontakter, så den kan sende invitationer til alle dine venner.Clientomdirigerer browseren til siden
2. Client ‘a og inkluderer i anmodningen Autoriseringsserverog en eller flere Denne ID bruges til at identificere, Redirect URI, Respons Type (tilladelser), som den har brug for. Omfang, der anmodes om af verificerer dig ved eventuelt at bede om brugernavn og adgangskode.
3. Autoriseringsserver præsenterer et
4. Autoriseringsserver (bekræftelses)skema med en liste over alle Samtykke , der anmodes om af Omfang, der anmodes om af‘om. Du accepterer eller afviser. Clientomdirigerer dig til hjemmesiden
5. Autoriseringsserver ‘a, ved at bruge Client(autoriseringskoden). Redirect URI sammen med Autoriseringskode kontakter direkte
6. Client ‘om (uden om browseren Autoriseringsserver‘a) og sender sikkert. Resource Ownerog) og sender sikkert Denne ID bruges til at identificere, Dette er et kodeord, som kun er kendt af og Autoriseringskode.
7. Autoriseringsserver tjekker data og svarer med En nøgle, som klienten vil bruge til at kommunikere med‘en (adgangstoken).
8. Now Client kan bruges En nøgle, som klienten vil bruge til at kommunikere med til at sende en anmodning om Ressourceserver for at få en liste over kontakter.

Client ID og Secret

Lang tid før du gav Terrible Pun of the Day adgang til kontakterne, etablerede Client og Authorization Server et samarbejde. Authorization Server genererede Client ID og Client Secret (nogle gange kaldet App ID og App Secret) og sendte dem til Client’en for yderligere interaktion inden for OAuth.

«— Hej! Jeg vil gerne arbejde sammen med dig! — Det er ikke noget problem! Her er dine Client ID og Secret!»

Navnet antyder, at Client Secret skal holdes hemmeligt, så kun Client og Authorization Server kender det. For det er med hjælp fra det, at Authorization Server bekræfter ægtheden af Client’en.

Men det er ikke alt… Venligst byd OpenID Connect velkommen!

OAuth 2.0 er udelukkende designet til autorisation — til at give adgang til data og funktioner fra én applikation til en anden. OpenID Connect (OIDC) — er et tyndt lag over OAuth 2.0, der tilføjer log-in og profiloplysninger om den bruger, der er logget ind. Organiseringen af log-in sessionen kaldes ofte autentificering [authentication], mens oplysningerne om den bruger, der er logget ind (dvs. om Resource Owner‘en), — personlige data [identity]. Hvis Authorization Server understøtter OIDC, kaldes den nogle gange identitetsudbyder [identity provider], da den giver Client‘en oplysninger om Resource OwnerKlienthemmelighed

OpenID Connect muliggør implementeringen af scenarier, hvor enkeltlog-in kan anvendes på mange applikationer, — denne tilgang er også kendt som single sign-on (SSO). For eksempel kan en applikation understøtte SSO-integration med sociale netværk som Facebook eller Twitter, hvilket giver brugerne mulighed for at bruge en konto, de allerede har og foretrækker.

Flowet (flow) i OpenID Connect ser ligesom OAuth ud. Den eneste forskel er, at i den oprindelige anmodning er den anvendte specifikke scope — openid, — og Client modtager til sidst som En nøgle, som klienten vil bruge til at kommunikere med, og ID Token.

Ligesom i OAuth flowet er En nøgle, som klienten vil bruge til at kommunikere med i OpenID Connect — en værdi, der ikke er forståelig for Client‘en. Set fra Client‘s synspunkt En nøgle, som klienten vil bruge til at kommunikere med repræsenterer det en streng af tegn, der sendes med hver anmodning til Ressourceserver‘en, og den afgør, om tokenet er gyldigt. ID Token repræsenterer noget andet.

ID Token er en JWT

ID Token — det er en særligt formateret streng af tegn, kendt som JSON Web Token eller JWT (nogle gange udtales JWT som «jots»). For external observers, JWT may seem like incomprehensible gibberish; however, Client one can extract various information from the JWT, such as ID, username, login time, and expiration date, ID Tokenas well as any attempts to tamper with the JWT. The data inside ID Tokenis called claims [claims].

In the case of OIDC, there is a standard way for which Client it can request additional information about the identity, [identity] fra Autoriseringsserversuch as the email address, using En nøgle, som klienten vil bruge til at kommunikere med.

Additional information about OAuth and OIDC

So, we have briefly looked at the principles of OAuth and OIDC. Ready to dig deeper? Here are additional resources to help you learn more about OAuth 2.0 and OpenID Connect:

• What the Heck is OAuth?
• Nobody Cares About OAuth or OpenID Connect
• Implement the OAuth 2.0 Authorization Code with PKCE Flow
• What is the OAuth 2.0 Grant Type?
• OAuth 2.0 From the Command Line
• Build a Secure Node.js App with SQL Server

As usual, feel free to comment. To stay updated on our latest news, subscribe to Twitter og YouTube Okta for Developers!

P.S. fra oversætteren

Læs også på vores blog:

• «Sikkerhedsalfabetet i Kubernetes: autentifikation, autorisation, revision»;
• «Users and RBAC Authorization in Kubernetes»;
• «33+ værktøjer til sikkerhed i Kubernetes»;
• «Security for Docker Containers».

Kilde: habr.com