Viktige ting du trenger å vite om OAuth

OAuth er noe hver utvikler må vite om. Hvis du lager et frittstående program eller et tredjepartsprogram som integreres med en annen HTTP-tjeneste, må du vite hvordan OAuth fungerer for å gi brukerne en brukervennlig og godt integrert tjeneste.

Tanken er å gi klientapplikasjoner en begrenset tilgang til brukerinformasjon uten å dele brukerlegitimasjon eller passord. OAuth framework er ansvarlig for utvekslingene som kreves før en applikasjon får informasjonen din.

Anta at du vil registrere deg for Dev.til (som er et flott sted for utviklere å utveksle ideer), lar de deg registrere deg ved hjelp av GitHub-kontoen din. Hvordan skjer det?? Hvordan ville de vite at du eier GitHub-kontoen som du registrerer deg med?

Enda viktigere, hvordan sikrer du at Dev.to overskrider ikke grensene når det gjelder informasjonen din som er lagret hos GitHub?

OAuth-deltakere

Vi vil holde oss til eksemplet med Atom-redaktørens GitHub-plugin som lar utviklere skyve kode til GitHub direkte ved hjelp av Atom-grensesnittet. Årsaken til dette som et eksempel er fordi GitHub ikke skjuler detaljene bak scenen, og du får se hva som skjer under panseret.

Før vi går inn i detaljene til OAuths arbeid. La oss sette scenen ved å kjenne igjen alle deltakerne i utvekslingen:

1. Ressourceeier eller bruker: Denne brukeren er den som har tilgang til kontoinformasjonen (lese og / eller skrive) for å få den til å fungere med et program.
2. Klient: Dette er applikasjonen som søker din tillatelse til å få tilgang til informasjonen din fra en annen tjeneste. I vårt eksempel er Atom editor klienten.
3. Ressurs: Ressurs er din faktiske informasjon som sitter på serverne på et eksternt sted. Dette er tilgjengelig via et API hvis klienten får passende tillatelser.
4. Autorisasjonsserver: Også grensesnittet via en API. Denne serveren vedlikeholdes av tjenesteleverandøren (GitHub i vårt eksempel). Både autorisasjonsserveren og ressursserveren blir referert til som API fordi de administreres av en enhet, i dette tilfellet GitHub, og utsettes som en API for klientutvikleren.

OAuth-registrering

Prosessen starter når klientapplikasjonen utvikles. Du kan gå til ressursleverandøren og registrere deg med utviklerportalen eller API-delen på nettstedet. Du må også oppgi en tilbakeringings-URL der brukeren vil bli omdirigert etter å ha godtatt eller avvist for å gi appen nødvendige tillatelser.

For eksempel, hvis du går til GitHub → Innstillinger → Utviklerinnstillinger og klikker på “Registrer en ny applikasjon”. Dette vil gi deg en klient-ID som kan offentliggjøres og a Klienthemmelighet som utviklerorganisasjonen må holde ... vel hemmelig.

Etter at klient-ID og hemmelighet er gitt til deg, utvikleren, deg må holde dem trygge og sikre da de ikke vises av autorisasjonsserveren igjen. Det samme gjelder for andre tokens som blir kastet rundt (Mer om tokens senere).

OAuth 2 arbeidsflyt

Du har registrert søknaden din. Den er utviklet og testet, og nå er brukerne klare til å bruke den. En ny bruker når du registrerer deg hos tjenesten din, vil få vist muligheten for "Logg på med GitHub". Dette er det første trinnet.

Trinn 1: Autorisasjonsforespørsel

Autorisasjonsforespørselen er den delen der et nytt vindu (eller en lignende ledetekst) åpnes med ressurssiden og ber brukerne logge på. Hvis du allerede er logget inn på den enheten, hoppes dette trinnet over og du blir bare spurt av GitHub om du vil gi tilgang til Atom-klientappen. Dette er mye mer gjennomsiktig i tilfelle Atom fordi de ber deg om å gå til GitHub-nettstedet manuelt og gi dem tillatelse.

Når du besøker URL-en, blir du bedt om tillatelse.

Legg merke til URL-en som viser at dette er en sikker (HTTPS) webside av GitHub.Inc. Nå kan du, brukeren, være sikker på at du kommuniserer direkte med GitHub. Atom venter rett og slett, ganske utenom veien.

I motsetning til Atom, laster de fleste klientappene automatisk på påloggings- eller tillatelsessiden. Selv om dette er veldig praktisk, kan det også misbrukes, hvis klientappen bestemmer seg for å åpne en phishing-lenke. For å unngå dette, må du alltid sjekke nettadressen du blir omdirigert til, og sørge for at den er riktig URL og bruker HTTPS-protokollen.

Trinn 2: Få autorisasjonsstipend

For å varsle Atom-klienten får du et token (et autorisasjonstilskudd) som deretter sendes til Atom-klienten.

Når brukeren har gjort dette, er brukerens jobb ferdig. (Faktisk er en typisk bruker ikke engang klar over utveksling av autorisasjonstilskudd. GitHubs eksempel ble valgt for å vise at dette er hva som skjer).

Trinn 3: Få tilgangstoken

Autorisasjonstilskuddet er fremdeles ikke den enheten som gir klienten tilgang til brukerinformasjon. Det oppnås ved å bruke noe som kalles et tilgangstoken. Hvilken klientappen vil prøve å få i dette trinnet.

For å gjøre dette, må klienten nå gi autorisasjonstjenesten til autorisasjonsserveren sammen med et bevis på sin egen identitet. Identiteten bekreftes ved hjelp av klient-ID og klienthemmelighet som ble gitt til klientappen tidligere.

Identitetsverifiseringen gjøres for å sikre at brukeren ikke blir lurt til å bruke en skjemmende app som utgir seg for å være en legitim app. For eksempel, hvis noen bestemmer seg for å navngi sin kjørbare fil som Atom med samme navn, kan bruker og logo bli lurt til å gi tilgang til en klient som kan misbruke informasjonen din. De kan snuse eller til og med handle uten ditt samtykke. Autorisasjonsserveren sørger for at klienten faktisk er det den ser ut til brukerne.

Når identiteten er bekreftet og godkjenningstildelingen er akseptert, kaster autorisasjonsserveren et token til klientappen. Tenk på tokenet som en kombinasjon av både brukernavn og passord som kan gis til ressursserveren for å få tilgang til en bestemt beskyttet ressurs som ressurseieren ga deg tilgang til.

Til slutt, ved å bruke dette token, kan appen nå få tilgang til nødvendig brukerinformasjon og andre ressurser fra ressursserveren.

Legg merke til hvordan i dette hele utveksle det faktiske brukernavnet og passordet aldri ble delt med klienten? Det er skjønnheten til OAuth. I stedet for å gi brukernavn og passord som gir appen all tilgang til ressursen, bruker den tokens i stedet. Og et token kan bare få begrenset tilgang til ressursen.

Tilbakekalling av tillatelser

Anta at du mister tilgang til enheten din som hadde den autoriserte klientappen. Du kan logge på GitHub og gå til Innstillinger → Programmer → Autoriserte OAuth-apper for å tilbakekalle autorisasjonstilskudd og tilgangstoken. Jeg vil gjøre det samme, siden autorisasjonstilskuddet ble vist i skjermbildene ovenfor.

Nå som du har et fugleperspektiv på hvordan OAuth 2.Du kan lese mer om autorisasjonstilskudd og andre finere detaljer i protokollen og hvordan API-anrop gjøres her.