Важни неща, които трябва да знаете за OAuth

OAuth е нещо, за което всеки разработчик трябва да знае. Ако правите самостоятелно приложение или приложение на трета страна, което се интегрира с друга HTTP услуга, трябва да знаете как работи OAuth, за да предостави на вашите потребители лесна за използване и добре интегрирана услуга.

Идеята е да се позволи на клиентските приложения ограничен достъп до потребителска информация, без никога да споделят потребителски идентификационни данни или парола. OAuth Framework е отговорен за обмена, който е необходим преди приложението да получи вашата информация.

Да предположим, че искате да се регистрирате за Dev.до (което е чудесно място за разработчици да обменят идеи) те ви позволяват да се регистрирате с помощта на вашия акаунт в GitHub. Как става това? Как биха разбрали, че притежавате акаунта в GitHub, с който се регистрирате?

По-важното е как да гарантирате, че Dev.to не надхвърля границите си, когато става въпрос за вашата информация, съхранявана с GitHub?

Участници в OAuth

Ще се придържаме към примера на приставката GitHub на редактора на Atom, която позволява на разработчиците да изпращат код към GitHub директно с помощта на интерфейса Atom. Причината за това като пример е, че GitHub не скрива подробностите зад сцената и можете да видите какво се случва под капака.

Преди да влезем в подробностите в работата на OAuth. Нека поставим сцената, като разпознаем всички участници в обмена:

1. Собственик на ресурс или потребител: Този потребител е този, чиято информация за акаунта трябва да бъде достъпна (прочетена и / или писана), за да може тя да работи с приложение.
2. Клиент: Това е приложението, което търси вашето разрешение за достъп до вашата информация от друга услуга. В нашия пример Atom Editor е клиентът.
3. Ресурс: Ресурсът е вашата действителна информация, която седи на сървърите на някакво отдалечено място. Това може да бъде достъпно чрез API, ако на клиента се предоставят подходящи разрешения.
4. Сървър за оторизация: Също така се свързва чрез API. Този сървър се поддържа от доставчика на услуги (GitHub в нашия пример). И сървърът за упълномощаване, и сървърът за ресурси се наричат ​​API, тъй като се управляват от един обект, в този случай GitHub, и се излагат като API на разработчика на клиента.

Регистрация в OAuth

Процесът започва, когато се разработва клиентското приложение. Можете да отидете при доставчика на ресурси и да се регистрирате с портала на разработчика или API раздела на уебсайта. Също така ще трябва да предоставите URL адрес за обратно извикване, където потребителят ще бъде пренасочен след приемане или отхвърляне, за да даде на приложението необходимите разрешения.

Например, ако отидете на GitHub → Настройки → Настройки за програмисти и кликнете върху „Регистрирайте ново приложение“. Това би ви предоставило a Идентификатор на клиента които могат да бъдат публично достояние и a Клиентска тайна което организацията на разработчиците трябва да пази ... добре в тайна.

След като идентификаторът и тайната на клиента са предоставени на вас, на разработчика, на вас трябва да пазете ги на сигурно място, тъй като те няма да бъдат показани от сървъра за оторизация отново. Същото важи и за всички други символи, които биха били хвърлени (Повече за символите по-късно).

Работен процес на OAuth 2

Регистрирали сте молбата си. Той е разработен и тестван и сега потребителите са готови да го използват. На нов потребител при регистрация във вашата услуга ще бъде показана опцията „Вход с GitHub“. Това е първата стъпка.

Стъпка 1: Искане за разрешение

Искането за упълномощаване е частта, в която се отваря нов прозорец (или подобен подкана) с уеб страницата на ресурса и изисква потребителите да влязат. Ако вече сте влезли в системата на това устройство, тази стъпка се пропуска и просто ви питат от GitHub дали искате да дадете достъп до клиентското приложение Atom. Това е много по-прозрачно в случай на Atom, тъй като те искат ръчно да отидете на уебсайта на GitHub и да им дадете разрешение.

При посещение на URL адреса ще бъдете помолени за разрешение.

Забележете, че URL адресът, който показва, че това е защитена (HTTPS) уеб страница от GitHub.Вкл. Сега вие, потребителят, можете да сте сигурни, че взаимодействате директно с GitHub. Атом просто чака, доста далеч.

За разлика от Atom, повечето клиентски приложения автоматично зареждат страницата за вход или разрешения. Въпреки че това е много удобно, то може да бъде злоупотребено, ако клиентското приложение реши да отвори фишинг връзка. За да избегнете това, винаги трябва да проверявате URL адреса, към който сте пренасочени, и да се уверите, че е правилен URL адрес и използва протокола HTTPS.

Стъпка 2: Получаване на разрешение за разрешение

За да уведомите клиента Atom, получавате токен (разрешение за предоставяне), който след това се изпраща на клиента Atom.

След като потребителят направи това, работата на потребителя е завършена. (Всъщност един типичен потребител дори не е наясно с размяната на разрешение за предоставяне. Примерът на GitHub беше избран, за да покаже, че това се случва).

Стъпка 3: Получаване на маркера за достъп

Разрешението за оторизация все още не е субектът, който дава на клиента достъп до потребителска информация. Това се получава чрез използване на нещо, наречено маркер за достъп. Кое клиентско приложение ще се опита да получи в тази стъпка.

За да направи това, клиентът сега ще трябва да предостави разрешение за разрешаване на сървъра за оторизация заедно с доказателство за собствената си самоличност. Идентичността се проверява с помощта на идентификатора на клиента и тайната на клиента, които са били предоставени на клиентското приложение по-рано.

Проверката на самоличността се прави, за да се гарантира, че потребителят не е подмамен да използва нечисто приложение, което се представя за законно приложение. Например, ако някой реши да назове своя изпълним като Atom със същото име, лого и функционалност, потребителят може да бъде подмамен да предостави достъп на клиент, който може да използва неправилно вашата информация. Те могат да подслушват или дори да действат без вашето съгласие. Упълномощаващият сървър гарантира, че клиентът наистина е такъв, какъвто изглежда на своите потребители.

След като идентичността е проверена и разрешението за одобрение е прието, сървърът за оторизация хвърля маркер в клиентското приложение. Помислете за маркера като комбинация от потребителско име и парола, които могат да бъдат дадени на сървъра на ресурсите за достъп до определен защитен ресурс, до който собственикът на ресурса ви е разрешил достъп.

И накрая, използвайки този маркер, приложението вече може да получи достъп до необходимата потребителска информация и други ресурси от ресурсния сървър.

Забележете как в целия този обмен действителното потребителско име и парола никога не се споделят с клиента? Това е красотата на OAuth. Вместо да дава потребителско име и пароли, които да предоставят на приложението целия достъп до ресурса, вместо това той използва символи. И токен може да получи само ограничен достъп до ресурса.

Отнемане на разрешения

Да предположим, че губите достъп до вашето устройство, в което има оторизирано клиентско приложение. Можете да влезете в GitHub и да отидете в Настройки → Приложения → Оторизирани приложения на OAuth, за да отмените разрешението за достъп и маркера за достъп. Ще постъпя по същия начин, тъй като в горните скрийншотове публичното показване на разрешението беше разрешено.

Сега, когато имате птичи поглед как OAuth 2.Можете да прочетете повече за разрешенията за оторизация и други по-фини подробности за протокола и как се извършват API извикванията тук.