Давай разберем шаги на примере Яндекс OAuth для логина пользователей в другом приложении.
Вообще по правилам OpenID Connect все сделано у Google, но поскольку на практике сейчас скорее всего столкнемся с интеграцией с Яндексом, решила рассмотреть его флоу.
1️⃣ Пользователь в браузере открывает PetApp и нажимает кнопку: «Войти с Яндекс ID»
2️⃣ PetApp перенаправляет пользователя на страницу Яндекс OAuth. Для этого используется запрос на эндпойнт /authorize Яндекса:
https://oauth.yandex.ru/authorize?
response_type=code
&client_id=pet-app
&redirect_uri=https://pet.app.ru/oauth/callback
&scope=login:info%20login:email
response_type=code означает, что PetApp просит вернуть ему код подтверждения для дальнейшего получения токена
client_id=pet-app — PetApp ранее зарегистрировался в Яндекс OAuth, получил идентификатор клиента и теперь передает его в запросе.
Остальные параметры в случае Яндекс OAuth необязательны, они могут браться из профиля клиента PetApp, но покажу основные:
redirect_uri — URL, на который Яндекс перенаправит пользователя после того, как тот разрешит PetApp доступ.
scope — это как раз запрашиваемые права
В доке Яндекс ID основной сценарий описан как OAuth 2.0, поэтому здесь запрашиваются просто права из списка: login:info login:email.
Если бы использовался протокол OIDC (как у Google, например), то мы бы передали в scope слово openid и запрашиваемые данные:
scope=openid profile email
3️⃣ Яндекс показывает страницу логина и возможно запрос разрешений
4️⃣ После успешного логина Яндекс редиректит обратно в PetApp на тот самый redirect_uri
5️⃣ Этот запрос принимает PetApp (обычно его бэк, но зависит от реализации), в нем он получает код подтверждения:
code=SOME_AUTH_CODE
6️⃣ Получив код авторизации, PetApp отправляет POST запрос в Яндекс на эндпойнт /token с только что полученным кодом SOME_AUTH_CODE
7️⃣ Яндекс возвращает access-токен и refresh-токен.
В случае OIDC обычно возвращается еще id_token с данными пользователя. Яндекс ID не возвращает id_token, у них для получения данных пользователя нужно использовать отдельный запрос на /info с access-токеном.
8️⃣ Приложение PetApp отправляет запрос на /info с access-токеном, находит или создает внутреннюю учетку для этого пользователя и связывает ее с аккаунтом Яндекса.
После этого PetApp уже создает свою сессию для пользователя: например, выдает собственную cookie/JWT и дальше работает с пользователем как со своей внутренней учетной записью.
✏️ Таким образом OAuth 2.0 выделяет основные эндпойнты:
🔴Authorization Endpoint — нужен, чтобы отправить пользователя на сервер авторизации и вернуть приложению-клиенту код авторизации.
🔴Token Endpoint — нужен, чтобы обменять код авторизации на access-токен.
🔴В OIDC в ответе от /token добавляется еще id_token и UserInfo Endpoint — для получения данных профиля пользователя.
Пример апишки провайдера можно посмотреть в доке Яндекс OAuth или VK ID или Google (повторюсь, у них как раз есть OpenID Connect).
OAuth 2.0 / OpenID Connect используется не только для работы с публичными провайдерами, но и для внутрикорпоративного доступа. В качестве внутрикорпоративного провайдера может выступать например Keycloak.
Keycloak — настоящий OpenID Connect Provider. У него есть все нужные эндпойнты (authorization endpoint, token endpoint, userinfo endpoint) плюс обычно он отвечает сразу за группы, роли, права, и в access-токен сразу может вкладывать группы и роли пользователя, которые затем будут анализироваться разными внутренними приложениями для определения того, что разрешено этому пользователю.
Ещё у меня был пост про организацию доступа с помощью access и refresh токенов.
Чтобы не перегружать пост, я совсем не затронула тему безопасности и специальных параметров, которые передаются в запросах OAuth 2.0 для верификации участников. Поставьте 🦆, если нужно это разобрать в отдельном посте.
Сталкивались ли вы с вопросами по OAuth 2.0 / OIDC на собесах или с реализацией на практике?