Sådan fungerer OAuth — autorisationskodeflowet

Sådan fungerer OAuth — autorisationskodeflowet

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs de tre kolonner fra venstre mod højre: Autorisation, Tokenudveksling, Beskyttet ressource.
• Hver række er én parts del af historien — brugerens række ligger øverst og ressourceserverens nederst, så brugerens samtykke og serverens validering rammer det midterste ind.
• Pile, der springer mellem rækker — som koden, der vender tilbage til klienten — er reelle netværksbeskeder mellem parterne; pile inden for en række er den parts egne trin.

Autorisationsdansen

»Brugeren klikker på ’Log ind med udbyder’« begynder i brugerens række og leverer videre til »Klienten viderestiller brugeren til autorisationsserveren«. Viderestillingen er OAuths definerende træk: den tager brugeren UD af klientappen og over til udbyderen, hvor »Brugeren logger ind og godkender de ønskede scopes« sker. Samtykkeskærmen — ikke bare selve loginet — er det trin, der betyder noget: brugeren vælger præcis, hvad klienten må gøre. »Autorisationsserveren returnerer en autorisationskode til klienten« giver kontrollen tilbage til appen, men kun med en kode, ikke et token.

Tokenudvekslingen

»Klienten veksler koden og sin client secret til et adgangstoken« krydser fra klientens række ind i autorisationsserverens. Det er i dette trin, at klienten beviser, at den er en legitim applikation, ved at fremvise både den kode, den modtog, OG sin registrerede client secret — så en stjålet kode alene er ikke nok. »Autorisationsserveren udsteder adgangstokenet« er det øjeblik, hvor samtykkebeslutningen bliver til en konkret rettighed: en streng, der siger, hvad klienten må gøre, og hvor længe.

At bruge tokenet

»Klienten kalder ressourceserveren med adgangstokenet« krydser ind i banegruppen »Ressourceserver«, og »Ressourceserveren validerer tokenet og returnerer brugerens data« er gevinsten. Ressourceserveren ser aldrig brugerens adgangskode eller samtykkeskærmen — den tjekker kun tokenet. »Brugeren ser sine data inde i appen« lukker sløjfen tilbage i brugerens række: set fra brugerens synsvinkel loggede de ind én gang, og appen fik deres data.

Key relationships and takeaways

• Brugerens adgangskode gives kun til autorisationsserveren — klienten og ressourceserveren ser den aldrig.
• Samtykket, altså de scopes, er selve tildelingen; adgangstokenet er den tildeling i maskinlæsbar form.
• Autorisationskoden er kortlivet og ubrugelig uden klientens client secret — to faktorer beskytter vekslingen.
• Adgangstokens udløber; refresh-tokens udsteder i stilhed nye uden endnu en samtykkeskærm.
• Ressourceserverens eneste opgave er at validere tokenet, og det holder parterne løst koblet.

When to use this visual

• At forklare et produktteam, hvorfor »Log ind med Google« er sikkert, og hvad samtykkeskærmen beder om.
• At vælge et OAuth-flow: autorisationskodeflowet her over for implicit flow eller client credentials i andre scenarier.
• At revidere, hvor loginoplysninger og tokens faktisk bevæger sig i jeres integration.

Sådan fungerer det

1. Omdøb parterne til jeres eget system

   Erstat de fire banegrupper med jeres reelle deltagere — jeres webapp, jeres identitetsudbyder, jeres API — så grænserne afspejler det system, I dokumenterer.

2. Tilføj de scopes, I beder om

   Notér de faktiske scopes på samtykketrinnet sammen med en bemærkning om, hvorfor hvert enkelt er nødvendigt, så reviewere kan se beslutningen om mindste privilegium.

3. Tegn refresh-vejen

   Tilføj en gren efter tokenets udløb: klienten fremviser sit refresh-token og får et nyt adgangstoken uden en samtykkeskærm, og grenen ender i sin egen eksplicitte tilstand.

4. Modellér fejltilfældene

   Tilføj afvisningsgrenene — en afvist samtykkeskærm, en ugyldig kode, et udløbet eller tilbagekaldt token — hver med det fejlsvar, den giver.

Ofte stillede spørgsmål

Hvad er OAuth, og hvorfor findes det?

OAuth er en standard for delegering. Den lader en applikation tilgå en brugers data hos en anden tjeneste på brugerens vegne, uden at applikationen nogensinde ser brugerens adgangskode. Brugeren autentificerer sig én gang hos autorisationsserveren og godkender bestemte tilladelser (scopes); appen modtager et token, den kan bruge. Netop den adskillelse af ansvar er det, de fire banegrupper i diagrammet står for.

Hvad er forskellen på en autorisationskode og et adgangstoken?

En autorisationskode er en kortlivet mellemværdi, klienten modtager, efter brugeren har givet samtykke; i sig selv giver den ingen adgang. Klienten veksler koden — sammen med sin registrerede client secret — til et adgangstoken, som er den faktiske rettighed, der bruges til at kalde ressourceserveren. Det er den todelte veksling, der lader klienten bevise sin identitet ved token-endpointet.

Hvorfor giver brugeren ikke sin adgangskode til appen?

Fordi appen kun har brug for begrænset adgang, der kan trækkes tilbage — at læse en profil, ikke at eje en konto. Fik appen adgangskoden, ville den have fuld adgang for altid, og brugeren kunne ikke trække én app tilbage uden at skifte adgangskode alle steder. OAuth bytter en adgangskode til et afgrænset token med udløb, som brugeren kan trække tilbage uafhængigt.

Hvad er scopes?

Scopes er de konkrete tilladelser, brugeren giver, for eksempel »læs e-mail« eller »skriv til kalender«. De vises på samtykkeskærmen og bliver kodet ind i adgangstokenet. Ressourceserveren håndhæver dem, så et token med scope til at læse ikke kan skrive — mindste privilegium er bygget ind i protokollen i stedet for at hvile på klientens gode opførsel.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis det OAuth-lærred, du ser her, som dit eget diagram, omdøb parterne til jeres egne tjenester, og notér de scopes, I beder om.

Redigér dette diagram i QueryChart (FlowJam)