SSO Docs

Appearance

Направление: сервис без пользователя (M2M) ​

Client Credentials Grant — когда токен нужен сервису самому по себе, без участия человека: микросервис, cron-задача, CI/CD пайплайн, интеграция между бэкендами.

Предполагается, что клиент уже создан (02-client.md).

Запрос токена ​

bash
curl -X POST http://localhost:3002/token \
  -d "grant_type=client_credentials" \
  -d "client_id=<client_id>" \
  -d "client_secret=<client_secret>" \
  -d "scope=read:data write:data"
json
{
  "access_token": "<JWT>",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read:data"
}

Если у клиента задан allowedScopes (см. 02-client.md) — запрошенные scope фильтруются по этому списку, в ответе останутся только разрешённые.

Чем отличается от пользовательского потока ​

  • Нет refresh_token. Когда токен истечёт — запросите новый тем же запросом. Обновлять нечего, client_secret и есть постоянные учётные данные сервиса.
  • Нет id_token — это не аутентификация человека, ID Token тут не имеет смысла.
  • sub в JWT равен client_id — токен идентифицирует сервис, а не пользователя:
json
{
  "sub": "my-service",
  "client_id": "my-service",
  "scope": "read:data",
  "iss": "http://localhost:3002",
  "aud": "my-service",
  "exp": 1735000000
}

Хранение секрета ​

client_secret для M2M-клиента — это фактически пароль сервиса. Держите его в переменных окружения или секрет-хранилище инфраструктуры (Vault, Secrets Manager, CI secret), не в репозитории. План на случай утечки или компрометации — 06-operations.md.

Проверка токена на стороне ресурс-сервера ​

Если ваш API получает такие токены от других сервисов и должен сам их валидировать — либо проверяйте подпись JWT через /jwks локально, либо используйте /introspect (см. 06-operations.md) — второй вариант дороже по латентности, но сразу учитывает отзыв токена.