#oauth #openid-connect
#oauth #OpenID-connect
Вопрос:
В потоке кода авторизации. Интерфейс может отправлять код аутентификации на серверную часть, а серверная часть может использовать код запроса токена с сервера аутентификации.
Теперь представьте, что у нас есть интерфейс SPA и используется PKCE. Возможно ли, что интерфейс отправляет код на серверную часть, а серверная часть запрашивает токен, используя свои учетные данные клиента? Я имею в виду, что серверная часть не знает секрет ключа подтверждения, сгенерированного интерфейсом.
Ответ №1:
Вы бы не стали смешивать и сопоставлять PKCE с секретом клиента, но распространенным решением является прокси-передача сообщения о предоставлении кода авторизации через серверную часть:
- Отправьте верификатор PKCE из браузера на серверную часть
- Затем отправьте верификатор на сервер авторизации
Это может быть механизм для хранения токенов доступа, или токенов обновления, или и того, и другого вне браузера. В качестве примера, мой образец SPA работает следующим образом.
Комментарии:
1. Спасибо! Еще один вопрос. Разрешено ли в OAuth, чтобы серверная часть получала токен (созданный интерфейсом с использованием pkce) без pkce, но со своими собственными учетными данными клиента? Я имею в виду, что интерфейс в этом сценарии использует pkce, а учетные данные бэкэнд-клиента.
2. Это не сработает — вы либо используете поток кода авторизации (с секретом клиента), либо поток кода авторизации (PKCE). Сервер авторизации проверяет второй шаг (предоставление кода авторизации) каждого потока в зависимости от параметров первого шага (перенаправление авторизации).