Относительно этой проблемы и API этого (setCodeVerifier) в AppAuth
Похоже, мы не можем установить только вызов кода отдельно и игнорировать кодчасть верификатора потока кода аутентификации AppAuth, которая предотвращает следующий поток, включающий службу с мобильным приложением и связанный бэкэнд:
- мобильное приложение запрашивает доступ к API-интерфейсам внутреннего сервера
- Бэкэнд-сервер отрицает необходимостьlogin
- Бэкэнд-сервер создает вызов кода PKCE и верификатор кода
- Бэкэнд-сервер отправляет вызов кода (но не верификатор) в мобильное приложение вместе с бэкэнд-сервером Oauth2 clientId
- Мобильное приложение выполняет предоставление кода авторизации с помощью вызова кода, предоставляемого внутренним сервером и внутренним сервером clientId
- Мобильное приложение отправляет код авторизации обратно на внутренний сервер (обратите внимание, что без верификатора еще никто не имеет всех частей дляполучить токены доступа / id)
- Бэкэнд-сервер теперь обменивается аутентификационными даннымиОн имеет только верификатор кода, который он знает для токенов доступа / идентификатора и создает сеанс пользователя на бэкэнде
- Теперь токен доступа / идентификатора можно отправить обратно в мобильное приложение для использования с API-интерфейсами Google, а также использоватьдля делегированного управления доступом к внутреннему серверу приложения.То есть.наше мобильное приложение для взаимодействия с внутренним сервером защищено с помощью того же токена доступа / идентификатора, который используется для защиты связи между нашей серверной службой и серверами ресурсов Google.
В связи с проблемой связанного стек-потока, описанной выше, PKCE не требуется вслучай, когда секрет клиента использует бэкэнды, но это все еще открывает мобильное приложение от перехвата ключа авторизации.Если я что-то упустил, разве предложенный выше поток не даст только бэкэнд-серверу возможность получать токены доступа / идентификатора, в то же время позволяя пользователю получить все преимущества Oauth2 в собственном приложении?
Кажется, что это невозможно с текущим API AppAuth или любыми другими библиотеками, которые я нашел где-либо.Я что-то пропустил?По сути, вы можете видеть мобильное приложение в качестве внешнего интерфейса входа в Oauth2 для внутреннего сервера, который является настоящим клиентским приложением.
Заранее спасибо.
Для дальнейшего ознакомления со свойствами дизайна япоиск, который привел меня, чтобы найти это следующим образом:
- Мобильное приложение, поддерживаемое серверным веб-сервером
- Вход в Google Oauth2 с использованием потока кода авторизации
- Защита кода авторизациичерез PKCE
- Совместное использование токенов между клиентами (технически есть только один клиент, поэтому я думаю, что более правильно описать собственное мобильное приложение и серверную часть как своего рода двухкомпонентный клиент, который разделяет поток кода аутентификации Oauth2ответственность и получаемые токены)
- Single ClientId (внутренний сервер)
- Устранение необходимости в ClientSecret даже на внутреннем сервере