OAuth VKontakte: bruk for personlig vinning. Passordflyt for legitimasjon

Åpne den innebygde nettleseren med påloggingssiden
Brukeren blir bedt om å bekrefte at rettigheter er gitt.
Hvis brukeren samtykker, blir nettleseren omdirigert til en stubbeside i fragmentet (etter #) som URL-en er lagt til tilgangstoken
Applikasjonen avskjærer viderekoblingen og mottar tilgangstoken fra sidens adresse

Dette alternativet krever å heve nettleservinduet i applikasjonen, men krever ikke serverdelen og et ekstra server-til-server-kall for utveksling Godkjennelseskoden på tilgangstoken.

Eksempel

Åpne nettleseren med påloggingssiden:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Vert: connect.mail.ru

Etter at brukeren gir tillatelser, skjer en omdirigering til en standard stubbside, for Mail.Ru er dette connect.mail.ru/oauth/success.html:
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

Søknaden må avskjære den siste viderekoblingen og hentes fra adressen access_token og bruke den til å få tilgang til beskyttede ressurser.

Autorisasjon med innlogging og passord

Autorisasjon med pålogging og passord er en enkel POST-forespørsel, som et resultat av at den returnerer tilgangstoken. Denne ordningen er ikke noe ny, men er inkludert i standarden for generalitet og anbefales kun brukt når andre autorisasjonsalternativer ikke er tilgjengelige.

Eksempel

> POST /oauth/token HTTP/1.1 > Vert: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=password&client_id=31337&client_secret=deadbeef&username=api@corp.mail.ru& password= qwerty< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
Beskrivelse i spesifikasjonen

Gjenoppretter tidligere autorisasjon

Som oftest, tilgangstoken Det har begrenset periode egnethet. Dette kan for eksempel være nyttig hvis det sendes over åpne kanaler. For å unngå å tvinge brukeren til å logge på etter utløp tilgangstoken"og, i alle alternativene ovenfor, i tillegg til tilgangstoken"kanskje komme tilbake igjen oppdater token. Du kan bruke den til å få tilgangstoken ved å bruke en HTTP-forespørsel, som ligner på autorisasjon ved bruk av pålogging og passord.

Eksempel

> POST /oauth/token HTTP/1.1 > Vert: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }

Hvis du bruker Mail.Ru Mail, trenger du ikke å bekymre deg for sikkerheten til dataene dine. Takk til OAuth  — autorisasjon.

I denne artikkelen ønsker vi å fortelle hele sannheten om denne teknologien. om det, Hvorfor er det viktig.

Hva er en protokollOAuth?

Ifølge statistikken har hver bruker i gjennomsnitt tre postkasser. Å sjekke dem alle, spesielt hvis de er på forskjellige nettsteder, er ikke veldig praktisk. I Mail.Ru Mail kan du konfigurere innsamlingen av brev fra postbokser på andre domener ().

Hvorfor bruke postsamleren i MailMail.Rutrygt?

Vanligvis, når du setter opp samleren, må du skrive inn navn, postboksadresse og passord. For å sikre sikker overføring av dataene dine har Mail.Ru Mail lenge brukt kryptering av disse dataene ved bruk av protokoller SSL. Og for å eliminere behovet for å overføre passord, implementerte vi innsamling av brev ved hjelp av OAuth. Denne protokollen tillater programmet ikke be om eller lagre pålogginger og passord.

Hvordan det fungerer?

La oss si at du bestemmer deg for å sette opp en samler av brev fra Yandex-post i din postkasse Mail.Ru. Takket være protokollen OAuth Mail.Ru mail vil ikke be om login og passord fra Yandex mail, men vil be om eneste rett til innsyn.

Bare klikk "Legg til postboks" og Mail vil ha tilgang til den blir tilbakekalt av deg.

Men vi vet ikke om passordet ditt.

Nyttige råd!

Og til slutt, hvis du bestemmer deg for å sette opp en e-postsamler fra Mail.Ru-postkassen på en tredjepart postvesen– sørg for at den bruker en protokoll OAuth. Hvis ikke, anbefaler vi ikke at du risikerer sikkerheten til dataene dine.

Vi håper denne artikkelen var nyttig for deg. Hvis du har spørsmål, spør i kommentarene.

I 2010 startet arbeidet med en fullstendig ny verson OAuth 2.0-protokoll, som ikke vil være bakoverkompatibel med OAuth 1.0. I oktober 2012 ble OAuth 2.0-rammeverket publisert i RFC 6749, og bruken av tokenbæreren i RFC 6750, begge standardene sporer kommentarforespørsler. Ytterligere RFC-er er fortsatt under utvikling.

Det var flere forutsetninger for å lage OAuth 2.0. Først av alt er OAuth ganske ikke-triviell å bruke på klient side. Et av målene våre når vi utvikler den nye OAuth er å forenkle utviklingen klientapplikasjoner. For det andre, til tross for implementeringen av tre metoder (kalt flyter) angitt i standarden for å skaffe et token (unik identifikator) for autorisasjon: for nettapplikasjoner, skrivebordsklienter og mobile klienter, faktisk er alle tre metodene slått sammen til én. Og for det tredje viste protokollen seg å være dårlig skalerbar. Det er planlagt å legge til:

6 nye strømmer.

User-Agent Flow - for klienter som kjører inne i en brukeragent (vanligvis en nettleser). Nettserverstrøm ( Internett server Flow - for klienter som er en del av en serverwebapplikasjon, tilgjengelig via HTTP-forespørsler. Device Flow - Egnet for klienter som kjører på begrensede enheter, men hvor slutt bruker Det har separat tilgang til en nettleser på en annen datamaskin eller enhet. Brukernavn og passordstrøm (Brukernavn og Passord Flow – Brukes i tilfeller der brukeren stoler på at klienten håndterer legitimasjonen, men det vil fortsatt ikke være ønskelig å la klienten lagre brukernavnet og passordet. Denne tråden er kun egnet når det finnes høy grad tillit mellom bruker og klient. Klientlegitimasjonsflyt – Klienten bruker sin legitimasjon for å få et token. Assertion Flow - Klienten sender en påstand, for eksempel en SAML-påstand, til autorisasjonsserveren i bytte mot et token. Applikasjoner kjører på stasjonær datamaskin eller mobil enhet kan implementeres ved hjelp av trådene ovenfor.

Bærertegn.

Autorisasjonsmetoden er lik eksisterende metode autorisasjon ved hjelp av informasjonskapsler. I dette tilfellet brukes tokenet direkte som en hemmelighet (selve det faktum å ha tokenet autoriserer klienten) og overføres over HTTPS. Dette lar deg få tilgang til API via enkle skript(for eksempel ved å bruke cURL).

Forenklet signatur.

Signaturen er kraftig forenklet for å eliminere behovet for spesiell analyse, koding og parametersortering.

Kortvarige tokens med langsiktig autorisasjon.

I stedet for å utstede et token med lang levetid (som lang tid kan være kompromittert), gir serveren kortsiktig tilgang og langsiktig mulighet til å oppdatere tokenet uten brukerinteraksjon.

Separasjon av roller.

Ulike servere kan være ansvarlige for autorisasjon og for å gi tilgang til API.

Det er verdt å merke seg at selv om OAuth 2.0-standarden ennå ikke er godkjent, brukes den allerede av noen tjenester. For eksempel Graph Sosial API Facebook støtter kun OAuth 2.0.

Forskjellen mellom OAuth og OpenID

Det er en misforståelse at OAuth er en utvidelse av OpenID-protokollen. Dette er faktisk ikke sant. Selv om OpenID og OAuth har mange likheter, er sistnevnte en frittstående protokoll som på ingen måte er relatert til OpenID.

Tidsstempel og Nonce

For å forhindre trusselen om avspillingsforespørsler, bruker OAuth en nonce og et tidsstempel. Begrepet "nonce" betyr at, gitt tid brukes én gang og er en unik tilfeldig streng med bokstaver og tall som er ment å identifisere hver signerte forespørsel unikt. Å ha unik identifikator For hver forespørsel vil tjenesteleverandøren kunne forhindre gjenbruksforespørsler. Dette betyr at klienten genererer en unik streng for hver forespørsel den sender til serveren, og serveren holder styr på alle nonces som brukes for å forhindre at de brukes en gang til.

Å bruke nonces kan være svært kostbart for serveren, da de krever permanent lagring av alle mottatte nonces. For å gjøre implementeringen enklere, legger OAuth til et tidsstempel til hver forespørsel, som lar serveren bare lagre nonce i en begrenset periode. Når en forespørsel kommer med et tidsstempel som er tidligere enn det lagrede tidspunktet, avvises det da serveren ikke lenger har en varsling fra det tidspunktet.

Legitimasjon og tokens

OAuth bruker tre typer autorisasjon: klientlegitimasjon (forbruker nøkkel og hemmelig eller klientlegitimasjon), midlertidig legitimasjon (forespørselstoken og hemmelig eller midlertidig legitimasjon) og tokens (tilgangstoken og hemmelig eller tokenlegitimasjon).

Klientlegitimasjon brukes til å autentisere klienten. Dette lar serveren samle informasjon om klienter. Ved å bruke sine tjenester tilbyr serveren noen klienter spesiell behandling som struping fri tilgang, eller gi ressurseieren mer detaljert informasjon om klienter som forsøker å få tilgang til deres beskyttede ressurser. I noen tilfeller kan det hende at klientlegitimasjonen ikke er sikker og kan bare brukes til informasjonsformål, for eksempel i skrivebordsapplikasjoner.

Tokenet brukes i stedet for navnet og passordet til ressurseieren. Ressurseieren deler ikke sin legitimasjon med klienten, men autoriserer heller serveren til å utstede klienten et token - en spesiell klasse med legitimasjon som representerer gi tilgang. Klienten bruker tokenet for å få tilgang til den beskyttede ressursen uten å vite ressurseierens passord.

Et token består av en identifikator, vanligvis (men ikke alltid) et tilfeldig sett med bokstaver og tall som er unikt og vanskelig å gjette, og en nøkkel for å beskytte tokenet fra å bli brukt uvedkommende. Tokenet er begrenset i omfang og varighet, og kan trekkes tilbake når som helst av ressurseieren uten å påvirke andre tokens utstedt til andre klienter.

OAuth-autorisasjonsprosessen bruker også et sett med midlertidig legitimasjon som brukes til å bestemme autorisasjonsforespørselen. For å imøtekomme ulike typer klienter (nett, desktop, mobil osv.), gir midlertidig legitimasjon ekstra fleksibilitet og sikkerhet.

Hvordan OAuth fungerer

Hvordan OAuth-protokollen fungerer

La oss forklare bruken av OAuth-protokollen ved å bruke et eksempel. La oss si at en bruker (ressurseier) ønsker å skrive ut bildene (ressursene) som er lastet opp til nettstedet "photos.example.net" (server) ved å bruke utskriftstjenesten "printer.example.net" (klient).

Klienten, ved hjelp av HTTPS-protokollen, sender en forespørsel til serveren som inneholder klientidentifikatoren, et tidsstempel, en tilbakeringingsadresse som tokenet skal returneres til, typen digital signatur som brukes, og selve signaturen.
Serveren bekrefter forespørselen og svarer klienten med et tilgangstoken og en del av den delte hemmeligheten.
Klienten overfører tokenet til ressurseieren (brukeren) og omdirigerer det til serveren for autorisasjon.
Serveren, etter å ha mottatt et token fra brukeren, ber ham om pålogging og passord, og hvis autentiseringen er vellykket, ber brukeren om å bekrefte klientens tilgang til ressurser (autorisasjon), hvoretter brukeren blir omdirigert av serveren til klient.
Klienten sender et token til serveren via TLS og ber om tilgang til ressurser.
Serveren bekrefter forespørselen og svarer klienten med et nytt tilgangstoken.
Ved å bruke det nye tokenet kontakter klienten serveren for ressurser.
Serveren bekrefter forespørselen og gir ressurser.

Dette eksemplet beskriver en flyt med en autorisasjonskode (Authorization Code Flow). I tillegg beskriver OAuth 2.0-standarden følgende flyter:

Implisitt tilskuddsflyt

Forskjellen fra verifikasjonskodeflyten er at klienten ikke er autentisert av serveren og tilgangstokenet utstedes av serveren etter autorisasjonsforespørselen.

Oppdaterer en utløpt tilgangstokenflyt

Forskjeller av denne strømmen fra eksemplet ovenfor som følger: ved trinn 2 utsteder serveren, i tillegg til tilgangstokenet, som har en begrenset levetid, et oppdateringstoken; ved trinn 8 sjekker serveren om tilgangstokenet er gyldig (i betydningen utløp av levetiden), og avhengig av dette gir den enten tilgang til ressurser eller krever at tilgangstokenet oppdateres (som gis ved presentasjon av oppdateringstokenet).

Påloggingsinformasjon for ressurseiere

I denne flyten gir ressurseieren klienten en pålogging og passord, han sender dem til serveren og mottar et token for å få tilgang til ressursene. Til tross for at denne driftsmåten er noe i strid med konseptet med å lage en protokoll, er den beskrevet i spesifikasjonen.

Klientlegitimasjonsflyt

I denne modusen hvordan protokollen fungerer, gir serveren et tilgangstoken etter at klienten har overført sin bruker og passord, som tidligere ble satt av autorisasjonsserveren (spesifikasjonen spesifiserer ikke nøyaktig hvordan). Faktisk gjennomgår klienten umiddelbart både autorisasjon og autentisering.

OAuth støtter to metoder for autentisering av meldinger fra klienten: HMAC -SHA1 og RSA -SHA1. Det er mulig å sende meldinger uten signatur, da vises "ren tekst" i signaturtypefeltet. Men i dette tilfellet, i henhold til spesifikasjonen, må forbindelsen mellom klienten og serveren etableres via SSL eller TLS.

Portaler som bruker OAuth

Diskusjon

I juli 2012 kunngjorde Eran Hammer, den nåværende redaktøren av OAuth 2.0-standarden, sin oppsigelse etter tre års arbeid med den nye standarden, og ba om at navnet hans ble fjernet fra spesifikasjonene. Han har snakket om sine synspunkter på sin nettside. Han holdt senere en presentasjon. .

Notater

se også

Linker

Wikimedia Foundation. 2010.

Åpne den innebygde nettleseren med påloggingssiden
Brukeren blir bedt om å bekrefte at rettigheter er gitt.
Hvis brukeren samtykker, blir nettleseren omdirigert til en stubbeside i fragmentet (etter #) som URL-en er lagt til tilgangstoken
Applikasjonen avskjærer viderekoblingen og mottar tilgangstoken fra sidens adresse

Dette alternativet krever å heve nettleservinduet i applikasjonen, men krever ikke serverdelen og et ekstra server-til-server-kall for utveksling Godkjennelseskoden på tilgangstoken.

Eksempel

Åpne nettleseren med påloggingssiden:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Vert: connect.mail.ru

Søknaden må avskjære den siste viderekoblingen og hentes fra adressen access_token og bruke den til å få tilgang til beskyttede ressurser.

Autorisasjon med innlogging og passord

Eksempel

Gjenoppretter tidligere autorisasjon

Som oftest, tilgangstoken har begrenset holdbarhet. Dette kan for eksempel være nyttig hvis det sendes over åpne kanaler. For å unngå å tvinge brukeren til å logge på etter utløp tilgangstoken"og, i alle alternativene ovenfor, i tillegg til tilgangstoken"kanskje komme tilbake igjen oppdater token. Du kan bruke den til å få tilgangstoken ved å bruke en HTTP-forespørsel, som ligner på autorisasjon ved bruk av pålogging og passord.

Eksempel

OAuth 2 er et autorisasjonsrammeverk som lar søknader mottas begrenset tilgang til brukerkontoer via HTTP, som for eksempel Facebook, GitHub Og DigitalOcean. Det fungerer ved å delegere brukeridentifikasjon til tjenesten som er vert for brukerkontoen og autorisasjonen tredjepartsapplikasjoner ha tilgang til regnskap bruker. OAuth 2 gir autorisasjonsflyter for skrivebord, nettapplikasjoner og mobile enheter.

Denne hvitboken er rettet mot applikasjonsutviklere og gir en oversikt over rollene OAuth 2, typer autoriserte tillatelser, situasjoner og flyter som brukes.

La oss starte med rollene OAuth 2!

OAuth-roller

Oauth definerer 4 roller:

Ressurseier
Klient
Ressursserver
Autorisasjonsserver

Vi vil bryte ned hver rolle i de følgende underavsnittene.

Ressurseier: Bruker

Ressurseieren er brukeren som bruker applikasjonen for å få tilgang til kontoen. Applikasjonens tilgang til brukerens konto er begrenset av omfanget av autorisasjonstillatelser (for eksempel lese eller skrive).

Ressurs-/autorisasjonsserver: API

Ressursserveren lagrer beskyttede brukerkontoer, og autorisasjonsserveren bekrefter brukerens identitet og utsteder deretter tilgangstokener til applikasjonen.

Fra applikasjonsutviklernes synspunkt utfører tjeneste-API begge rollene, både som ressursserver og som autorisasjonsserver. Vi vil omdirigere til begge disse kombinerte rollene, både tjenesterollen og API-rollen.

Klient: applikasjon

Klienten er et program som ønsker å få tilgang til brukerens konto. Før det kan gjøre dette, må det tillates av brukeren og autorisasjonen må verifiseres av API.

Nå har du en ide om hva OAuth-roller er, la oss ta en titt på et diagram over hvordan de generelt samhandler med hverandre:

Her er mer detaljert forklaring trinn i diagrammet:

Applikasjonen ber om tillatelse fra brukeren til å få tilgang til tjenesteressurser
Hvis brukeren har godkjent forespørselen, mottar applikasjonen autorisasjonsbevilgning
Applikasjonen ber om et tilgangstoken fra autorisasjonsserveren (service API), som gir bevis på autentisiteten og gir autorisasjon
Hvis applikasjonens identitet er ekte og autorisasjonsbevilgningen er gyldig, utsteder autorisasjonsserveren (API) et tilgangstoken til applikasjonen. Autorisasjonen er fullført.
Applikasjonen ber om en ressurs fra en ressursserver (API) og gir et tilgangstoken for å bevise sin identitet
Hvis tilgangstokenet er gyldig, sender ressursserveren (API) ressursen til applikasjonen

Den faktiske flyten av denne prosessen vil variere avhengig av typen autorisasjonsbevilgning som brukes - dette er generell idé. Vi skal studere Forskjellige typer gitt i neste avsnitt.

Søknadsregistrering

Før bruker OAuth i søknaden din må du registrere søknaden din hos tjenesten. Dette gjøres gjennom registreringsskjemaet i utvikler- eller API-delen av tjenestenettstedet, der du vil oppgi følgende informasjon(og sannsynligvis detaljert informasjon om søknaden din):

Programnavn
Søknadsnettsted
Omdiriger URI eller URL Ring tilbake

URI-omdirigering brukes der tjenesten vil omdirigere brukeren etter at applikasjonen din er autorisert eller avslått, derav den delen av applikasjonen din som vil håndtere autorisasjonskoder eller tilgangstokener.

Klient-ID og hemmelig kode klient

Når søknaden din er registrert, vil tjenesten utstede "klientlegitimasjon" i form av en klient-ID og klienthemmelighet. Klient-ID-en er en offentlig streng som brukes av tjeneste-API for å identifisere applikasjonen, og brukes også til å konstruere autorisasjons-URLer som presenteres for brukere. Klienthemmeligheten brukes til å autentisere applikasjonen til API-tjenesten når applikasjonen ber om tilgang til brukerens konto og må holdes hemmelig mellom applikasjonen og APIen.

Tildeling av autorisasjon

I abstrakt protokollstrøm Ovenfor beskriver de fire første trinnene hvordan du får autorisasjonsbevilgningen og tilgangstokenet. Typen autorisasjon som gis avhenger av metoden som brukes av applikasjonen for å be om autorisasjon og tilskuddstypene til de støttede APIene. OAuth 2 definerer 4 tilskuddstyper, som hver er nyttig i forskjellige situasjoner:

Godkjennelseskoden: brukes sammen med applikasjoner på serversiden

Implisitt (skjulthet): brukes sammen med mobilapper eller nettapper (apper som kjører på brukerens enhet)

: brukes sammen med klarerte applikasjoner, for eksempel de som eies av selve tjenesten

Kundelegitimasjon: brukes med API-tilgangsapplikasjoner

Vi vil nå beskrive tilbudstyper mer detaljert, deres brukstilfeller og flyter, i de følgende avsnittene.

Tilskuddstype: Godkjennelseskoden

Autorisasjonskodeleveringstypen er den mest brukte fordi den er optimalisert for serversideapplikasjoner hvor kilde vises ikke offentlig og konfidensialiteten til klientens hemmelige kode kan opprettholdes. Dette er en omdirigeringsbasert flyt, som betyr at applikasjonen må kunne samhandle med brukeragenten (dvs. brukerens nettleser) og motta API-autorisasjonskoder som rutes gjennom brukeragenten.

Trinn 1: Autorisasjonskodekobling

https://cloud.digitalocean.com/v1/oauth/authorize - API-autorisasjonsendepunkt
response_type=kode – spesifiserer at applikasjonen din ber om en autorisasjonskode
client_id=CLIENT_ID — applikasjonsklientidentifikator (verdien som API-en identifiserer applikasjonen med)
redirect_uri=CALLBACK_URL — stedet der tjenesten omdirigerer nettleseren etter at autorisasjonskoden er gitt
scope=read - definerer tilgangsnivået som applikasjonen ber om

Når en bruker klikker på en lenke, må de først logge på tjenesten for å bekrefte identiteten sin (med mindre de allerede er pålogget). Tjenesten vil da be dem om bekreftelse for å tillate eller nekte applikasjonen tilgang til kontoen deres. Her er et eksempel på en applikasjon som ber om tilgang til en konto:

Søknadsautorisasjon

Tillatelsesoversikt(tilgangsrettigheter)

Lesning

Autoriser søknaden Forby

Hvis brukeren klikker på "Autoriser applikasjon", omdirigerer tjenesten nettleseren til applikasjonens omdirigerings-URI som ble spesifisert under klientregistreringen, sammen med en autorisasjonskode. Omdirigeringen vil se slik ut (forutsatt at appadressen er "dropletbook.com"):

Trinn 4: Applikasjonen får et tilgangstoken

Applikasjonen ber om et tilgangstoken fra API ved å sende en autorisasjonskode sluttpunkt API-markør, sammen med detaljert informasjon om identifikasjon, herunder klientens hemmelige kode. Her er en eksempelforespørsel via POST til DigitalOcean token-endepunktet:

Trinn 5: Applikasjonen får et tilgangstoken

("access_token":"ACCESS_TOKEN","token_type":"bærer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":( "name":"Mark E. Mark","email":" [e-postbeskyttet] «}}

Søknaden er nå godkjent! Den kan bruke tokenet for å få tilgang til brukerens konto gjennom tjenestens API, med tilgangsbegrensninger inntil tokenet utløper eller oppheves. Hvis et oppdateringstoken har blitt bestått, kan det brukes til å be om nye tilgangstokener hvis det originale tokenet har utløpt.

Tilskuddstype: Implisitt (skjulthet)

Den implisitte tilskuddstypen brukes til mobilapplikasjoner og nettapplikasjoner (det vil si applikasjoner som kjører i en nettleser), der konfidensialiteten til klientens hemmelige kode ikke er garantert. Den implisitte bevilgningstypen er også en omdirigeringsbasert strøm, men tilgangstokenet gis til nettleseren for å sendes til applikasjonen slik at den kan nås av både brukeren og andre applikasjoner på brukerens enhet. I tillegg autentiserer ikke denne flyten applikasjonens identitet og er avhengig av en omdirigerings-URI (som ble registrert med tjenesten) for å tjene dette formålet.

Den implisitte tilskuddstypen støtter ikke oppdateringstokener.

Den implisitte bevilgningsflyten fungerer i utgangspunktet slik: brukeren blir bedt om å autorisere applikasjonen, deretter sender autorisasjonsserveren et tilgangstoken tilbake til nettleseren, som igjen sender det til applikasjonen. Hvis du er interessert i detaljer, les videre.

Med den implisitte bevilgningstypen får brukeren en autorisasjonslenke som ber om et token fra API-en. Denne lenken ser ut som en autorisasjonskodekobling, bortsett fra at den ber om et token i stedet for en kode (merk at forespørselstypen er "token"):

Merk

Når en bruker klikker på en lenke, må de først logge på tjenesten for å bekrefte identiteten sin (hvis de ikke allerede er pålogget). De vil da bli bedt av tjenesten om å tillate eller nekte applikasjonens tilgang til kontoen deres. . Her er et eksempel på en applikasjon som ber om tilgang til en konto:

Søknadsautorisasjon

Thedropletbook vil ha tillatelse til å få tilgang til kontoen din

Tillatelsesoversikt(tilgangsrettigheter)

Lesning

Autoriser søknaden Forby

Vi ser at "Thedropletbook App" ber om tillatelse til å lese kontoen " [e-postbeskyttet] ”.

Trinn 3: Nettleseren mottar et tilgangstoken med en omdirigerings-URI

Trinn 4: Nettleseren følger omdirigerings-URIen

Nettleseren følger omdirigerings-URIen, men beholder tilgangstokenet.

Trinn 5: Applikasjonen sender et tilgangstoken til utvinningsskriptet

Applikasjonen returnerer en side som inneholder et skript som kan trekke ut tilgangstokenet fra hele omdirigerings-URIen som nettleseren har lagret.

Trinn 6: Tilgangstokenet sendes til applikasjonen

Nettleseren kjører det angitte skriptet og sender det hentede tilgangstokenet til applikasjonen.

Merk: DigitalOcean støtter for øyeblikket ikke den implisitte bevilgningstypen, så lenken peker til en tenkt autorisasjonsserver på "oauth.example.com".

Tilskuddstype: Påloggingspassordressurseier

Med tildelingstypen for ressurseier for påloggingspassord gir brukeren sin tjenestelegitimasjon (brukernavn og passord) direkte til applikasjonen, som bruker påloggingsinformasjonen for å få et tilgangstoken fra tjenesten. Denne tilskuddstypen skal bare aktiveres på autorisasjonsserveren hvis andre flyter ikke er levedyktige. Den bør også brukes hvis applikasjonen er klarert av brukeren (for eksempel hvis den tilhører en tjeneste eller operativsystem datamaskin).

Passordflyt for legitimasjon

Når brukeren har oppgitt sin legitimasjon til applikasjonen, må den be om et tilgangstoken fra autorisasjonsserveren. En POST-forespørsel kan se omtrent slik ut:

Hvis brukerens legitimasjon er bekreftet, returnerer autorisasjonsserveren et tilgangstoken til applikasjonen. Søknaden er nå godkjent!

Merk: DigitalOcean støtter for øyeblikket ikke passordtypen for legitimasjon, så lenken peker til en tenkt autorisasjonsserver på "oauth.example.com".

Tilskuddstype: Kundelegitimasjon

Tildelingstypen klientlegitimasjon gir en applikasjon en måte å få tilgang til personlig konto service. Eksempler på når dette kan være nyttig er hvis en applikasjon ønsker å oppdatere sin registrerte beskrivelse eller omdirigere URI, eller få tilgang til andre data som er lagret på tjenestekontoen gjennom API.

Klientlegitimasjonsflyt

Applikasjonen ber om et tilgangstoken ved å sende legitimasjonen, klient-IDen og klienthemmeligheten til autorisasjonsserveren. Eksempel POST-forespørsel kan se slik ut:

Hvis klientens legitimasjon er bekreftet, returnerer autorisasjonsserveren et tilgangstoken til applikasjonen. Fra nå av har applikasjonen lov til å bruke hennes egen konto!

Merk: DigitalOcean støtter for øyeblikket ikke klientlegitimasjonstypen, så koblingen peker til en tenkt autorisasjonsserver på "oauth.example.com".

Eksempel på bruk av tilgangstoken

Når en applikasjon har et tilgangstoken, kan den bruke tokenet for å få tilgang til brukerens konto gjennom API, med begrensninger på tilgang til tokenet utløper eller blir tilbakekalt.

Her er et eksempel på en forespørsel-API som bruker krølle. Merk at den inkluderer et tilgangstoken:

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN" "https://api.digitalocean.com/v2/$OBJECT" ;

Forutsatt at tilgangstokenet er gyldig, vil API-en behandle forespørselen i henhold til dens tekniske spesifikasjoner. Hvis tilgangstokenet har utløpt eller på annen måte er ugyldig, vil API-en returnere en "invalid_request"-feil.

Oppdater tokenflyt

Når et tilgangstoken har utløpt, vil bruk av det til å lage en API-forespørsel resultere i en "Ugyldig token"-feil. På dette stadiet, hvis et oppdateringstoken ble inkludert i forespørselen da det opprinnelige tilgangstokenet ble utstedt, kan det brukes til å be om et nytt tilgangstoken fra autorisasjonsserveren. Her POST eksempel forespørsel som bruker et oppdateringstoken for å få et nytt tilgangstoken:

Konklusjon

Dette avslutter vår OAuth 2-veiledning. Du bør nå ha en god forståelse av hvordan OAuth 2 fungerer og når en bestemt autorisasjonsflyt skal brukes.

Hvis du vil lære mer om OAuth 2, sjekk ut disse nyttige ressursene:

Hvordan bruke OAuth-autentisering med DigitalOcean som bruker eller utvikler
Slik bruker du DigitalOcean API versjon 2
Autorisasjonsramme