Viktige ting du trenger å vite om OAuth

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

Tanken er å tillate klientapplikasjoner en begrenset tilgang til brukerinformasjon uten noen gang å dele brukeropplysning 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) de lar 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.til er ikke overskridende grenser når det gjelder informasjonen som er lagret med GitHub?

OAuth -deltakere

Vi vil holde oss til eksemplet på Atom Editor's 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 gjemmer detaljene bak scenen, og du får se hva som går under panseret.

Før vi kommer inn i minutiae av Oauths arbeid. La oss sette scenen ved å gjenkjenne alle deltakerne i utvekslingen:

1. Ressurseier eller bruker: Denne brukeren er den hvis kontoinformasjon må nås (lese og/eller skrive) for å få den til å fungere med en applikasjon.
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: Ressursen er din faktiske informasjon som sitter på serverne på et eksternt sted. Dette kan nås via et API hvis klienten får passende tillatelser.
4. Autorisasjonsserver: Også grensesnitt med via et API. Denne serveren opprettholdes 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 utsatt som API for klientutvikleren.

OAuth -registrering

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

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

Etter at klient -ID og hemmelighet er gitt deg, utvikleren, du må Hold dem trygge og sikre, da de ikke blir vist av autorisasjonsserveren igjen. Det samme gjelder alle andre symboler som vil bli kastet rundt (mer på symboler 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 med tjenesten din, vil bli vist muligheten til å "logge 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) åpner med ressurssiden og ber brukerne logge inn. Hvis du allerede er logget inn, på den enheten, blir dette trinnet hoppet over, og du blir ganske enkelt spurt av GitHub om du vil gi tilgang til Atom Client -appen. Dette er mye mer gjennomsiktig i tilfelle atom fordi de ber deg om å gå til GitHub nettsted manuelt og gi dem tillatelse.

Når du besøker nettadressen, blir du bedt om tillatelse.

Legg merke til nettadressen som viser at dette er en sikker (https) webside av github.Inc. Nå kan du, brukeren, være sikker på at du direkte samhandler med GitHub. Atom venter ganske enkelt, ganske ut av veien.

I motsetning til Atom, laster de fleste klientapper automatisk opp 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 det er riktig url og bruker HTTPS -protokollen.

Trinn 2: Få autorisasjonstilskuddet

For å varsle Atom -klienten, får du et token (et autorisasjonsstipend) som deretter blir sendt til Atom -klienten.

Når brukeren gjør dette, er brukerens jobb gjort. (Faktisk er en typisk bruker ikke engang klar over utvekslingen av autorisasjonstilskudd. Githubs eksempel ble valgt for å vise at det er dette som skjer).

Trinn 3: Få tilgangstokenet

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

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

Identitetsbekreftelsen gjøres for å sikre at brukeren ikke blir lurt til å bruke en skummel app som later til å være en legitim app. For eksempel, hvis noen bestemmer seg for å navngi sin kjørbare som atom med samme navn, kan brukere og funksjonalitetsbruker 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 sikrer at klienten virkelig er det den ser ut for brukerne sine.

Når identiteten er bekreftet og autorisasjonstilskuddet er akseptert, kaster autorisasjonsserveren et symbol på 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 tillot deg å få tilgang til.

Til slutt, ved å bruke dette tokenet, kan appen nå få tilgang til den nødvendige brukerinformasjonen og andre ressurser fra ressursserveren.

Legg merke til hvordan i hele utvekslingen det faktiske brukernavnet og passordet der aldri deles med klienten? Det er skjønnheten i Oauth. I stedet for å gi brukernavn og passord som vil gi appen all tilgang til ressursen, bruker den symboler i stedet. Og et token kan bare få en begrenset tilgang til ressursen.

Tilbakekalling av tillatelser

Anta at du mister tilgangen til enheten din som hadde den autoriserte klientappen i den. Du kan logge deg på GitHub og gå til Innstillinger → Programmer → Autoriserte OAuth -apper til å tilbakekalle autorisasjonsstipend og tilgangstoken. Jeg vil gjøre det samme, siden, i ovennevnte skjermbilder, ble autorisasjonstilskuddet offentlig vist.

Nå som du har et fuglepers syn på hvordan Oauth 2.Du kan lese mer om autorisasjonstilskuddene og andre finere detaljer om protokollen og hvordan API -samtalene blir gjort her.