OAuth и федеративная аутентификация

Пользователь аутентифицируется на authorization server, который редиректит обратно к клиенту с короткоживущим кодом. Клиент меняет код на токены прямым серверным вызовом. По редиректу едет только код, ведь URL попадают в логи.

state — неугадываемое значение, которое клиент генерирует, привязывает к сессии пользователя и шлёт в запросе авторизации. Сервер возвращает его в редиректе, а callback с несовпавшим state отвергается как подделанный.

Authorization server сверяет запрошенный redirect_uri с зарегистрированным значением посимвольно — схема, хост, порт и путь. Префиксная сверка или wildcard уводят похожий URL на чужой путь, куда и уедет authorization code.

JWT состоит из header, payload и подписи в base64url, соединённых точками. Header и payload закодированы, но не зашифрованы, их читает любой держатель. До доверия claims сервер проверяет подпись, затем iss, aud и exp.

Клиент создаёт случайный code_verifier, отправляет его хеш как code_challenge в запросе авторизации, затем предъявляет verifier на token endpoint. Код обменивается только при совпадении, что привязывает его к начавшему поток.

id_token — результат аутентификации для клиента: его aud равен client id, и он сообщает, кто вошёл. access_token — результат авторизации для API, непрозрачный клиенту. OAuth2 даёт доступ; OIDC говорит, кто пользователь.

Проверяющий, берущий алгоритм из header alg самого токена, может быть переведён с асимметричной схемы на симметричную, где публичный ключ — а он не секретен — становится ключом HMAC. Фиксируйте ожидаемый алгоритм и ключ издателя.

Шлюз раскодирует токен вместо проверки, поэтому токен без алгоритма не несёт подписи и всё равно принимается. Проверяйте фиксированным алгоритмом и ключом издателя, отвергайте любое иное значение alg, а claims читайте только после этого.

Client credentials подходит фоновому сервису, действующему от себя — без пользователя, редиректа и согласия. Клиент аутентифицируется и получает токен со своей идентичностью. Scopes задают допустимое, поэтому выдавайте минимум прав.

Браузерные, мобильные и серверные приложения от лица пользователя используют authorization code с PKCE; вызывающие без пользователя — client credentials. Implicit возвращал токены в URL, а password брал учётные данные, поэтому оба сняты.

Клиент кладёт случайный nonce в запрос авторизации и требует то же значение внутри id_token, привязывая токен к этому входу и блокируя повтор. Он также проверяет подпись издателя и сверяет iss, exp и aud.

Всё, что попало в URL — токен во фрагменте или query — оказывается в истории браузера, логах прокси и заголовках Referer, поэтому токенам место в заголовках. Ограничение аудитории отдельно: токен называет своё API.