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

Три стороны

Каждый OAuth flow (процесс авторизации) вовлекает три стороны. Понять, кто кому доверяет и почему, — значит сразу видеть, где гарантии безопасности держатся, а где рвутся при инциденте.

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

Вместе эти три роли означают: ни одна сторона не нуждается в полном доверии ко всем остальным. Клиент не узнаёт пароль, resource server не видит credential — только токен, подтверждающий разрешение. Без такого разделения компрометация одной стороны означала бы компрометацию всей системы.

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

Ты нанимаешь выгульщика собак. Ты не даёшь ему ключ от дома. Вместо этого идёшь в 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-токен отвечает: “кто пользователь?”