Какие варианты использования при авторизации системы в другой системе

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

Различаете ли вы случаи, когда система ходит в другую от своего имени и от имени пользователя, и можете ли описать интеграцию так, чтобы разработчики не гадали. Следом обычно спрашивают, чем аутентификация отличается от авторизации и где хранить секреты.

Как отвечать

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

• API-ключ: статичный секрет в заголовке. Просто, но ключ сам не истекает, поэтому нужны ротация и ограничение по IP;
• OAuth 2.0 Client Credentials: стандарт для межсервисных вызовов. Система получает короткоживущий токен по client_id и секрету или подписанному JWT, права задаются через scope;
• mTLS: взаимная проверка сертификатов. Частый выбор в банковских интеграциях, иногда в связке с OAuth;
• подпись запроса HMAC: тело и время запроса подписываются общим секретом, это защищает от подмены и повтора. Типично для вебхуков;
• OAuth 2.0 Authorization Code с PKCE: нужен доступ к данным пользователя, он сам даёт согласие, система получает токен с ограниченными правами;
• SAML и OpenID Connect: единый вход людей (SSO), а не межсервисный вызов.

В требованиях зафиксируйте способ, срок жизни токена и обновление, набор scope, место хранения секретов, ротацию ключей, коды 401 и 403 и поведение системы при отказе.

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

Ставят JWT в один ряд с OAuth. JWT это формат токена, его выдают в том числе по OAuth, и выбор формата не отвечает на вопрос, как система получит доступ.

Путают 401 и 403. Первый означает «не узнали, кто вы», второй «узнали, но прав нет».

Предлагают пересылать логин и пароль пользователя между системами. Актуальные рекомендации по безопасности OAuth запрещают такой grant, а хранение чужих паролей делает вашу систему точкой утечки.