Что такое OAuth и почему пароли — не ответ

Приложение для печати фото просит тебя “подключить Google Drive”. Ты вводишь свой пароль Google прямо в их форму. Теперь это приложение может читать каждый файл, письмо и фото в твоём аккаунте — навсегда. Одна утечка PrintPic — и все сервисы, подключённые через Google, скомпрометированы. OAuth существует потому, что это неправильный способ делиться доступом.

Три стороны

Каждый OAuth flow вовлекает три стороны:

1. Клиент (твоё приложение, например PrintPic). Хочет ограниченного доступа к ресурсу от имени пользователя. Никогда не видит пароль пользователя.
2. Authorization server (identity provider, например Google). Аутентифицирует пользователя, выдаёт токены. Единственная сторона, хранящая пароль.
3. Resource server (API, например Google Drive). Принимает токены для обработки запросов. Валидирует токены через authorization server.

Метафора выгульщика собак

Ты нанимаешь выгульщика собак. Ты не даёшь ему ключ от дома. Вместо этого идёшь в key kiosk (authorization server) и говоришь “Фрэнк может выгуливать собаку по вторникам 9–10”. Киоск печатает Фрэнку single-use карту, открывающую только заднюю калитку, только по вторникам, только на час. Фрэнк потерял карту — без проблем, отзываешь в киоске. Карта — это access-токен. Задняя калитка — resource API.

Два токена, два назначения

Успешный OAuth + OpenID Connect flow выдаёт два разных токена:

• Access token — авторизует API-вызовы. Клиент отправляет его в заголовке Authorization: Bearer. Говорит “держатель вправе делать X”. Resource server принимает его без знания identity пользователя.
• ID token — доказывает кто пользователь (слой OpenID Connect). Всегда JWT. Содержит claims вроде sub (стабильный user ID), email, name. Клиент читает его, чтобы знать кто только что вошёл. Никогда не отправляется в API.

Access-токен отвечает: “может ли это приложение делать X?” ID-токен отвечает: “кто пользователь?”