OAuth 2.0 в картинках

Иногда бывает сложно объяснить, как работает OAuth. Инфы в интернете много, но она вся мудрёная и порой противоречивая. Кажется, что некоторые авторы специально усложняют тему, чтобы выглядеть умнее.

А тема-то не такая сложная — успешный сценарий можно объяснить за один пост в телеге с одной sequence-диаграммой.

Участники:

👤 Пользователь — владеет ресурсами и авторизует ваше приложение на доступ к ним. Например, ему нужно разместить объявление, но вместо регистрации с логином и паролем он хочет «войти через Google».

💻 Ваше клиент-серверное приложение — например, доска объявлений, где вы хотите разрешить вход через Google.

🔐 OAuth провайдер — предоставляет сервер для авторизации и сервер для доступа к ресурсу. Например, Google предоставляет доступ к имени, email и ID пользователя.


🛠️ 5 шагов, чтобы реализовать «вход через Google»:

1️⃣ — Получить конфигурацию OAuth
Провайдеры предоставляют discovery-endpoint, который вернет актуальные url для OAuth протокола.
Рекомендуется запрашивать конфигурацию вместо хардкода или сохранения в конфиге.
Проверьте сами: https://accounts.google.com/.well-known/openid-configuration

2️⃣ — Отправить запрос на авторизацию
После нажатия на кнопку «Войти через Google» ваше клиентское приложение выполняет запрос в ваш бэкенд.
Ваш бэкенд перенаправляет клиента на URL, составленный с помощью authorization_endpoint из 1️⃣ и стандартных oauth-параметров:

1. response_type=(code|token) — Определяет flow: Auth Code или Implicit. Используйте code, т.к. иначе токен передается на клиент в query string, оставаясь в логах веб-серверов, и может быть украден с клиента

2. client_id — Публичный идентификатор вашего приложения, который вы получили через веб-интерфейс OAuth провайдера для разработчиков.

3. state Уникальный случайный код, который генерирует ваш бэкенд. Нужен, чтобы предотвратить CSRF атаки. В конце флоу помогает убедиться, что изначальный запрос был инициирован вашим приложением.

4. scope — Список типов ресурсов, к которым приложение запрашивает доступ. openid — для доступа к userinfo_endpoint из 1️⃣. calendar_read — чтение календаря.

3️⃣ — Пользователь взаимодействует с OAuth провайдером.
Обычно здесь пользователь вводит логин-пароль, проходит 2fa через sms, и т.д. Если пользователь уже залогинен на этом устройстве, то увидит просто кнопку "Предоставить доступ YourApp к информации о вас".

Этот процесс непрозрачен для вашего приложения, т.к. пользователь взаимодействует с OAuth провайдером через браузер без вашего участия.

4️⃣ — Получение токена
OAuth провайдер перенаправляет браузер обратно к вашему сервису, используя redirect_uri, который передал ваш бэкенд на шаге 2️⃣.

Параметры redirect_uri:
1. state — Должен соответствовать тому, который передал ваш бэкенд на шаге 2️⃣. Если не совпадает, — значит пользователь подвергся CSRF атаке.
2. code — Одноразовый код, сгенерированный oauth провайдером.

Ваш бэкенд делает запрос в OAuth Auth server для получения access_token и других.
После получения access_token ваш бэкенд использует его для запросов к ресурсам.

Auth Code flow безопаснее, чем implicit flow, потому что добавляется шаг взаимодействия вашего сервиса и OAuth провайдера для получения токена. Таким образом на клиенте не светятся никакие секреты, и вероятность их компрометации снижается.

5️⃣ — Получение ресурсов
Когда ваш сервис получает access_token, он может быть использован для вызова API сервера ресурсов сразу или в будущем.

access_token имеет ограниченный срок действия и его нужно регулярно обновлять с помощью refresh_token.

Доказательством аутентификации служит id_token. ID пользователя можно достать из поля sub (subject), раскодировав base64 JWT id_token.
Или обратиться к userinfo_uri, используя access_token.


Вот собственно и всё.
OAuth — это просто.
Распространите.

——

Специально для поста я перевел инфографику из статьи ув. тов. Phil Boutros.
На картинке к посту — превью. Сам pdf файл — чуть ниже.

Для закрепления материала можно поиграться в официальной OAuth 2.0 Playground