Viktiga saker du behöver veta om OAuth

OAuth är något som varje utvecklare måste veta om. Om du skapar en fristående applikation eller en tredjepartsapplikation som integreras med någon annan HTTP-tjänst, måste du veta hur OAuth fungerar för att ge dina användare en lättanvänd och välintegrerad tjänst.

Tanken är att ge klientapplikationer en begränsad åtkomst till användarinformation utan att någonsin dela användaruppgifter eller lösenord. OAuth-ramverket ansvarar för de utbyten som krävs innan en ansökan får din information.

Antag att du vill registrera dig för Dev.till (vilket är en utmärkt plats för utvecklare att utbyta idéer) låter de dig registrera dig med ditt GitHub-konto. Hur händer det?? Hur skulle de veta att du äger GitHub-kontot som du registrerar dig med?

Ännu viktigare, hur ser du till att Dev.to överskrider inte sina gränser när det gäller din information lagrad med GitHub?

OAuth-deltagare

Vi kommer att hålla oss till exemplet med Atom-redaktörens GitHub-plugin som gör det möjligt för utvecklare att skicka kod till GitHub direkt med Atom-gränssnittet. Anledningen till detta som ett exempel är att GitHub inte döljer detaljerna bakom scenen och du får se vad som går under huven.

Innan vi går in på detaljerna i OAuths arbete. Låt oss sätta scenen genom att känna igen alla deltagare i utbytet:

1. Resursägare eller användare: Den här användaren är den vars kontoinformation behöver nås (läs och / eller skriv) för att få den att fungera med en applikation.
2. Klient: Det här är applikationen som söker din tillåtelse att få tillgång till din information från en annan tjänst. I vårt exempel är Atom-redigeraren klienten.
3. Resurs: Resurs är din faktiska information som sitter på servrarna på någon avlägsen plats. Detta kan nås via ett API om klienten får lämpliga behörigheter.
4. Auktoriseringsserver: Gränssnittet också via ett API. Denna server underhålls av tjänsteleverantören (GitHub i vårt exempel). Både auktoriseringsservern och resursservern kallas API eftersom de hanteras av en enhet, i detta fall GitHub, och exponeras som ett API för klientutvecklaren.

OAuth-registrering

Processen startar när klientapplikationen utvecklas. Du kan gå till resursleverantören och registrera dig med deras utvecklarportal eller API-sektionen på webbplatsen. Du måste också ange en URL för återuppringning där användaren skulle omdirigeras efter att ha accepterat eller avvisat för att ge appen nödvändiga behörigheter.

Om du till exempel går till GitHub → Inställningar → Utvecklarinställningar och klickar på "Registrera en ny ansökan". Detta skulle ge dig en Klient ID som kan offentliggöras och Kundhemlighet som utvecklarorganisationen måste hålla ... väl hemlig.

Efter att klient-ID och hemlighet har tillhandahållits dig, utvecklaren, du måste håll dem säkra eftersom de inte kommer att visas av auktoriseringsservern igen. Detsamma gäller alla andra tokens som skulle slängas runt (Mer om tokens senare).

OAuth 2 arbetsflöde

Du har registrerat din ansökan. Den har utvecklats och testats och nu är användarna redo att använda den. En ny användare vid registrering med din tjänst skulle visas alternativet "Logga in med GitHub". Detta är det första steget.

Steg 1: Auktoriseringsbegäran

Behörighetsbegäran är den del där ett nytt fönster (eller en liknande fråga) öppnas med resurswebbsidan och ber användarna att logga in. Om du redan är inloggad på den enheten hoppas detta steg över och du blir helt enkelt frågad av GitHub om du vill ge åtkomst till Atom-klientappen. Detta är mycket mer transparent när det gäller Atom eftersom de ber dig att manuellt gå till GitHub-webbplatsen och ge dem tillstånd.

När du besöker webbadressen ombeds du om tillstånd.

Lägg märke till webbadressen som visar att detta är en säker (HTTPS) webbsida av GitHub.Inc. Nu kan du, användaren, vara säker på att du interagerar direkt med GitHub. Atom väntar helt enkelt helt ur vägen.

Till skillnad från Atom laddar de flesta klientappar automatiskt inloggnings- eller behörighetssidan. Även om detta är mycket bekvämt kan det också missbrukas om klientappen bestämmer sig för att öppna en phishing-länk. För att undvika detta måste du alltid kontrollera webbadressen du omdirigeras till och se till att den är korrekt URL och använder HTTPS-protokollet.

Steg 2: Få tillståndsbidraget

För att meddela Atom-klienten får du en token (ett auktorisationsbidrag) som sedan skickas till Atom-klienten.

När användaren har gjort detta är användarens jobb gjort. (Faktum är att en typisk användare inte ens är medveten om utbytet av auktorisationsbeviljande. GitHubs exempel valdes för att visa att detta är vad som händer).

Steg 3: Få åtkomsttoken

Auktorisationstilldelningen är fortfarande inte den enhet som ger klienten åtkomst till användarinformation. Det erhålls genom att använda något som kallas en åtkomsttoken. Vilket klientappen kommer att försöka få i det här steget.

För att göra detta måste klienten nu tillhandahålla auktorisationsbeviljandet till auktoriseringsservern tillsammans med ett bevis på sin egen identitet. Identiteten verifieras med hjälp av klient-ID och klienthemlighet som gavs till klientappen tidigare.

Identitetsverifieringen görs för att säkerställa att användaren inte luras att använda en onödig app som låtsas vara en legit app. Till exempel, om någon bestämmer sig för att namnge sin körbar som Atom med samma namn, kan logotypen och funktionalitetsanvändaren bli lurad att ge åtkomst till en klient som kan missbruka din information. De kan snoka eller till och med agera utan ditt samtycke. Auktoriseringsservern ser till att klienten verkligen är vad den ser ut för sina användare.

När identiteten har verifierats och godkännandebeviset har godkänts, kastar auktoriseringsservern en token till klientappen. Tänk på token som en kombination av både användarnamn och lösenord som kan ges till resursservern för att få åtkomst till en viss skyddad resurs som resursägaren gav dig tillgång till.

Slutligen kan appen med hjälp av denna token nu få tillgång till den nödvändiga användarinformationen och andra resurser från resursservern.

Lägg märke till hur i det här hela utbytet av det faktiska användarnamnet och lösenordet aldrig delas med klienten? Det är skönheten i OAuth. Istället för att ge användarnamn och lösenord som ger appen tillgång till resursen använder den istället tokens. Och en token kan bara få begränsad åtkomst till resursen.

Återkalla tillstånd

Antag att du tappar åtkomst till din enhet som hade den auktoriserade klientappen. Du kan logga in på GitHub och gå till Inställningar → Program → Auktoriserade OAuth-appar för att återkalla auktorisationsbeviljandet och åtkomsttoken. Jag kommer att göra detsamma, eftersom tillståndet beviljades i ovanstående skärmdumpar offentligt.

Nu när du har en fågelperspektiv på hur OAuth 2.Du kan läsa mer om auktorisationsbidrag och andra finare detaljer i protokollet och hur API-samtal görs här.