Vigtige ting, du har brug for at vide om OAuth

OAuth er noget, som enhver udvikler skal vide om. Hvis du laver en enkeltstående applikation eller en tredjepartsapplikation, der integreres med en anden HTTP-tjeneste, skal du vide, hvordan OAuth fungerer for at give dine brugere en brugervenlig og velintegreret service.

Ideen er at give klientapplikationer en begrænset adgang til brugeroplysninger uden nogensinde at dele brugeroplysninger eller adgangskode. OAuth framework er ansvarlig for de udvekslinger, der kræves, før en applikation får dine oplysninger.

Antag at du vil tilmelde dig Dev.til (hvilket er et godt sted for udviklere at udveksle ideer) lader de dig tilmelde dig ved hjælp af din GitHub-konto. Hvordan sker det?? Hvordan ville de vide, at du ejer den GitHub-konto, som du tilmelder dig med?

Endnu vigtigere, hvordan sikrer du, at Dev.to overskrider ikke sine grænser, når det kommer til dine oplysninger, der er gemt med GitHub?

OAuth-deltagere

Vi holder os til eksemplet med Atom-editorens GitHub-plugin, der giver udviklere mulighed for at skubbe kode til GitHub direkte ved hjælp af Atom-grænsefladen. Årsagen til dette som et eksempel er, at GitHub ikke skjuler detaljerne bag scenen, og du får se, hvad der foregår under emhætten.

Før vi går ind i detaljerne i OAuths arbejde. Lad os sætte scenen ved at genkende alle deltagerne i udvekslingen:

1. Ressourceejer eller bruger: Denne bruger er den, hvis kontooplysninger skal åbnes (læse og / eller skrive) for at få det til at fungere med en applikation.
2. Klient: Dette er applikationen, der søger din tilladelse til at få adgang til dine oplysninger fra en anden tjeneste. I vores eksempel er Atom-editor klienten.
3. Ressource: Ressource er din faktiske information, der sidder på serverne et eller andet sted. Dette kan tilgås via en API, hvis klienten får passende tilladelser.
4. Autorisationsserver: Også grænseflade med via en API. Denne server vedligeholdes af tjenesteudbyderen (GitHub i vores eksempel). Både autorisationsserveren og ressource-serveren kaldes API, fordi de administreres af en enhed, i dette tilfælde GitHub, og eksponeres som en API for klientudvikleren.

OAuth-registrering

Processen starter, når klientapplikationen udvikles. Du kan gå til ressourceudbyderen og tilmelde dig deres udviklerportal eller API-sektionen på webstedet. Du bliver også nødt til at angive en URL til tilbagekaldelse, hvor brugeren vil blive omdirigeret efter at have accepteret eller afvist for at give appen de nødvendige tilladelser.

For eksempel, hvis du går til GitHub → Indstillinger → Udviklerindstillinger og klikker på "Registrer en ny applikation". Dette vil give dig en Klient-id som kan offentliggøres og Klienthemmelighed som udviklerorganisationen skal holde ... godt hemmelig.

Efter at klient-id'et og hemmeligheden er givet til dig, udvikleren, dig skal hold dem sikre og sikre, da de ikke vises af autorisationsserveren igen. Det samme gælder for andre tokens, der ville blive kastet rundt (Mere om tokens senere).

OAuth 2 Workflow

Du har registreret din ansøgning. Det er udviklet og testet, og nu er brugerne klar til at bruge det. En ny bruger, når han tilmelder sig din tjeneste, får vist muligheden "Log ind med GitHub". Dette er det første skridt.

Trin 1: Autorisationsanmodning

Autorisationsanmodningen er den del, hvor et nyt vindue (eller en lignende prompt) åbnes med ressourcewebsiden og beder brugerne om at logge ind. Hvis du allerede er logget ind på den enhed, springes dette trin over, og du bliver simpelthen spurgt af GitHub, om du vil give adgang til Atom-klientappen. Dette er meget mere gennemsigtigt i tilfælde af Atom, fordi de beder dig om manuelt at gå til GitHub-webstedet og give dem tilladelsen.

Når du besøger URL'en, bliver du bedt om tilladelse.

Bemærk URL'en, der viser, at dette er en sikker (HTTPS) webside af GitHub.Inc. Nu kan du, brugeren, være sikker på, at du interagerer direkte med GitHub. Atom venter simpelthen ganske ude af vejen.

I modsætning til Atom indlæser de fleste klientapps automatisk login- eller tilladelsessiden. Selvom dette er meget praktisk, kan det også misbruges, hvis klientappen beslutter at åbne et phishing-link. For at undgå dette skal du altid kontrollere den URL, som du omdirigeres til, og sørge for at den er korrekt URL og bruger HTTPS-protokollen.

Trin 2: Få autorisationsstipendiet

For at underrette Atom-klienten får du et token (en autorisationsbevilling), som derefter sendes til Atom-klienten.

Når brugeren gør dette, er brugerens job færdig. (Faktisk er en typisk bruger ikke engang opmærksom på udvekslingen af ​​tilladelse. GitHubs eksempel blev valgt for at vise, at dette er hvad der sker).

Trin 3: Få adgangstoken

Autorisationsbevillingen er stadig ikke den enhed, der giver klienten adgang til brugeroplysninger. Det opnås ved hjælp af noget, der kaldes et adgangstoken. Hvilken klientapp vil forsøge at komme i dette trin.

For at gøre dette skal klienten nu levere autorisationsbevillingen til autorisationsserveren sammen med et bevis på sin egen identitet. Identiteten bekræftes ved hjælp af klient-id'et og klienthemmeligheden, der blev givet til klientappen tidligere.

Identitetsbekræftelsen udføres for at sikre, at brugeren ikke narres til at bruge en uhyggelig app, der foregiver at være en legitim app. For eksempel, hvis nogen beslutter at navngive deres eksekverbare som Atom med samme navn, kan bruger og logo og funktionalitet blive lokket til at give adgang til en klient, der kan misbruge dine oplysninger. De kan snuse eller endda handle uden dit samtykke. Autorisationsserveren sikrer, at klienten faktisk er, hvad den ser ud for sine brugere.

Når identiteten er bekræftet, og autorisationsbevillingen er accepteret, kaster autorisationsserveren et token til klientappen. Tænk på tokenet som en kombination af både brugernavn og adgangskode, som kan gives til ressourceserveren for at få adgang til en bestemt beskyttet ressource, som ressourceejeren gav dig adgang til.

Endelig, ved hjælp af dette token, kan appen nu få adgang til de krævede brugeroplysninger og andre ressourcer fra ressource-serveren.

Bemærk, hvordan i det hele udveksler det faktiske brugernavn og adgangskode, hvor de aldrig deles med klienten? Det er skønheden ved OAuth. I stedet for at give brugernavn og adgangskoder, der giver appen al adgang til ressourcen, bruger den i stedet tokens. Og et token kan kun få en begrænset adgang til ressourcen.

Tilbagekaldelse af tilladelser

Antag, at du mister adgang til din enhed, som havde den autoriserede klientapp. Du kan logge ind på GitHub og gå til Indstillinger → Applikationer → Autoriserede OAuth-apps for at tilbagekalde autorisationsbevillingen og adgangstokenet. Jeg vil gøre det samme, da autorisationsbevillingen blev vist offentligt i ovenstående skærmbilleder.

Nu hvor du har et fugleperspektiv af, hvordan OAuth 2.Du kan læse mere om tilladelsesbevillinger og andre mere detaljerede detaljer i protokollen, og hvordan API-opkald foretages her.