Как происходит взаимодействие между сервисом авторизации и сервисом статей при проверке токена

Что проверяют

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

Как отвечать

Сначала разведите роли. Сервис авторизации выдаёт токены и держит ключи. Сервис статей принимает запрос с заголовком Authorization: Bearer <token> и решает, пускать ли его.

• локальная проверка JWT: сервис авторизации подписывает токен приватным ключом (RS256 или ES256) и публикует публичные ключи через JWKS. Сервис статей скачивает их, кэширует и сам проверяет подпись, exp, iss и aud. В PyJWT это PyJWKClient и jwt.decode(token, key, algorithms=["RS256"], audience=...). Сетевого вызова на каждый запрос нет;
• интроспекция: токен непрозрачный, и сервис статей спрашивает у сервиса авторизации, жив ли он (эндпоинт по RFC 7662). Отзыв срабатывает сразу, но сервис авторизации участвует в каждом запросе и становится точкой отказа, поэтому ответ кэшируют на короткое время;
• отзыв при локальной проверке: короткий срок жизни access-токена, в пределах минут, плюс refresh-токен, а для срочной блокировки список отозванных jti в Redis.

В FastAPI проверку оформляют зависимостью через Depends, которая возвращает пользователя с ролями. Роли из токена говорят, что человеку разрешено в целом, а проверка «эта статья принадлежит автору» остаётся в сервисе статей: это его данные. Нет токена или он невалиден: ответ 401. Токен валиден, но прав не хватает: 403.

Где спотыкаются

Раздают всем сервисам общий секрет для HS256. Тогда любой сервис, знающий секрет, может выпустить токен от имени кого угодно.

Не фиксируют список алгоритмов и не проверяют aud. Токен, выпущенный для другого сервиса, спокойно проходит проверку.

Считают JWT зашифрованным. Он только подписан, содержимое читается любым base64-декодером, так что персональным данным в нём не место.