[Концепция] — Основы OAuth 2.0


Оригинальное содержание в этой ветке Твиттера


Привет, Дев,

Хотите зажечь на следующем свидании, рассказывая об OAuth 2.0? Тогда давайте поговорим о некоторых основах. Таким образом, вы дойдете до конца свидания со своим увлечением, и вам не понадобятся эти хорошие, сексуальные и обыденные поцелуи — черт возьми!

cc @sseraphini


Отказ от ответственности: Это не будет темой, объясняющей все сложности этого протокола/фреймворка, который мрачен и полон нюансов. Но оставайтесь там, если хотите понять некоторые основы.


Я обязательно написал OAuth 2.0, потому что это текущая версия, которую следует использовать. Существует OAuth 1.0, который уже устарел.

В любом случае, когда я пишу OAuth only, понимайте, что речь идет о текущей версии — 2.0, хорошо?


OAuth — это АВТОРИЗАЦИЯ, а не аутентификация! Конечно, чтобы получить возможность авторизации, необходимо пройти аутентификацию, но эта структура (RFC называет OAuth структурой) даже не вдается в эти детали. В нем говорится только о том, что он должен быть безопасным, адекватным и т.д. Это нормально? О, и это HTTP-фреймворк!


OAuth имеет четыре роли, и я собираюсь очень кратко рассказать о каждой из них. На практике вам не нужно глубоко разбираться в них, если только вы не реализуете протокол (ах, я называю OAuth протоколом, но думаю, что правильнее будет фреймворк).


Владелец ресурса:

Это «владелец» ресурса. Это может быть человек или услуга. Например, вы являетесь владельцем своих материалов на Facebook (фотографии, биография и т.д.), и именно вы разрешаете или запрещаете доступ к ним (теоретически, верно? lolrs).


Ресурсный сервер:

Здесь хранятся ваши защищенные ресурсы (например, ваши фотографии из Instagram). Этот сервер должен уметь обрабатывать маркеры доступа для предоставления, запрета и т.д. доступа к защищенным ресурсам.


Клиент:

По сути, это приложение, которое хочет получить доступ к защищенным ресурсам. (Эта часть важна сейчас, следите за новостями.) Приложение получает доступ к ресурсам ПО ИМЕНИ владельца ресурса. Вы знаете приложение, в которое вы входите с помощью Twitter? Значит, это будет Клиент, блз?


Сервер авторизации:

Это организация (сервер), которая выдает маркеры доступа. Это роль хранителя. Знаете, какие запросы вы делаете, чтобы получить маркер доступа? Итак, это сервер авторизации. Именно здесь OAuth как бы «берет тело» и не определяет, как работает аутентификация.


Теперь я собираюсь немного РАЗРУШИТЬ это понятие о роли и сервере. Хотя существует два сервера (Ресурс и Авторизация), ничто не мешает разместить их на одном сервере. Это важно! (Эта информация эквивалентна тому, как если бы вы впервые взяли за руку на свидании)

Конечно, ничто не мешает размещать их и в разных местах. Я просто хотел подчеркнуть, что OAuth не определяет это.


Теперь я хотел бы поговорить еще об одной вещи, о которой, как я вижу, многие люди не знают. Вы знаете знаменитый токен доступа в формате JWT? То, что вы помещаете в заголовок Authorization, декодируете его, а в нем куча всякой всячины? Таким образом, там МОЖЕТ быть атрибут под названием «sub».


Это «sub» означает субъект. Это атрибут, который идентифицирует владельца ресурса. Например, «суб» токена доступа может быть CPF или логин человека. (Поймите этот намек сейчас.) Когда этот атрибут существует, это означает, что Клиент ПРЕДСТАВЛЯЕТ этого субъекта!


Таким образом, все эти приложения, которые мы используем и делаем, где мы просим пользователя авторизоваться в социальной сети, например, токен доступа будет содержать этот «sub», идентифицирующий пользователя. Доверьтесь ему!


Это подводит нас к другой теме. OAuth также может использоваться для авторизации доступа к ресурсам, которые НЕ представляют человека/пользователя. Такой тип авторизации называется Machine to Machine (M2M). Токены доступа НЕ будут иметь атрибут «sub» в этих случаях.


Знание этого может облегчить вам задачу, когда вы хотите разрешить доступ только клиентам, представляющим пользователя. ( если «sub» отсутствует в JWT, возвращается HTTP 403 «отвали, сука!»).

(Эта информация вкуснее, чем поцелуй внутренней стороны руки вашего возлюбленного. Поверьте мне).


Я уже устал писать эту тему, и вы тоже устали ее читать, я знаю, но подождите еще немного, потому что я собираюсь поговорить о последней вещи, которую я считаю основной: типы грантов! Я не буду описывать каждую из них, потому что… есть такие, которые, ради Бога, понимаете? Очень сложно.


Типы грантов — это не что иное, как потоки для получения маркеров доступа! Иногда их называют потоками или потоками авторизации — это одно и то же.


Мини-шпаргалка по видам грантов:

Учетные данные клиента: используются в M2M авторизации, когда нет пользователей («как мне заставить мой бэкэнд позвонить вашему бэкэнду?»). Помните, что в этом потоке токен доступа не будет иметь «sub»!


Код авторизации: часто используется в приложениях, требующих авторизации для доступа к социальным сетям. Вы входите и авторизуетесь НА САЙТЕ социальной сети, после чего вас перенаправляют на приложение/сайт Клиента. Приходит код, Клиент меняет код бла-бла-бла… Сложный этот поток, и я никогда его не запомню.


Код устройства: для случаев, когда у вас нет браузера в потоке и/или достаточно ограничений. Если однажды вы захотите сделать консоль с ограничениями на использование браузеров, получающих токены доступа, то вам следует использовать именно этот тип гранта.


Refresh Token: чтобы использовать этот поток, вы должны сначала получить маркер доступа. Затем срок действия маркера доступа истекает, и вы обмениваете его на новый маркер доступа с помощью refresh token. Этот поток используется для того, чтобы вам не требовалось взаимодействие с пользователем для получения новых маркеров доступа.


Пароль: Этот поток устарел и не рекомендуется. Почему? Потому что вы вставляете свои учетные данные в клиент! Представьте себе приложение, которое просит вас войти в систему Facebook, но просит вас ввести свои учетные данные В ЭТОМ приложении? С ума сойти, правда? Если клиент не является надежным, не используйте этот поток!


Существуют и другие потоки, но именно эти я вижу наиболее часто используемыми.


О, я вспомнил какую-то чушь, которую часто видел! Клиенты, которые для каждого запроса вызывают конечную точку для получения маркера доступа! Серьезно, каждый раз, когда кто-то это пишет, погибает щенок тюленя. Не будьте таким человеком — используйте кэш, что угодно… Сотрудничайте с Authorization Server! 🙄


Если вы не покорите свою подругу этой речью об OAuth, я, честно говоря, не знаю, хороши ли вы еще, понимаете? Мне жаль.

О, мне даже не нужно этого говорить, верно? Если вы дочитали до конца, обнимите меня здесь 🤗.

Большое спасибо за мораль! 💕

Оцените статью
Procodings.ru
Добавить комментарий