Какой тип предоставления: неявный или аутентификационный код (без секретного ключа) подходит для одностраничного приложения (SPA)?

Question

Я прочитал несколько постов, в которых рассказывалось о том, как неявное предоставление представляет угрозу безопасности и почему после перенаправления в приложение следует использовать предоставление кода авторизации с запросом AJAX на сервер авторизации (без передачи client_secret на сервер аутентификации).

Теперьв 2019 году нет проблемы CORS, поскольку я могу разрешить домены приложений на сервере аутентификации.

У меня есть следующие проблемы

Если я использую неявное предоставление:

1. Теперь неявное предоставление имеет проблемы с безопасностью, поскольку сервер авторизации перенаправляет на сервер приложений с токеном в URL.
2. Если я установлю срок действия от 5 до 10 минут, после истечения срока действия пользователь будет перенаправлен на вход в систему, и это будет проблематично, особенно если он заполняет важную форму заявки.Что делать в этом сценарии?Обратите внимание, что в неявном разрешении нет маркера обновления для обновления новым токеном, поэтому токен обновления отсутствует.

Если я использую код авторизации: Предположим, если янажмите AJAX-запрос после перенаправления на основной сайт моего приложения и получите токен в обмен на код:

1. При авторизации кода используется client_secret.И в приложении javascript, где любой может увидеть код, мы не можем использовать секрет.
2. Предположим теперь, если я не использую client_secret.Есть несколько сайтов, которые используют сервер аутентификации, скажем, сайт 1, 2, 3. Теперь, если мы скажем, что не использовать секрет, любой может сделать запись узла на сервере nginx, которая будет иметь доменное имя моего сайта, но его собственный IP-адрес.В этом случае инъекция хоста является проблемой.Как с этим бороться?

Какой подход следует использовать здесь?Я более склонен к auth_code для SPA, но вопрос в том, как бороться с client_secret?

Спасибо за чтение.

Существует несколько ссылок, которые рекомендуют использовать предоставление кода авторизации вместо SPA.Несколько из нескольких ссылок:

https://www.oauth.com/oauth2-servers/single-page-apps/

https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926

Answer 1

Рекомендации 2019 года - использовать вариант PKCE потока кода авторизации, который не нуждается в секрете клиента: https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/

В моем блоге есть некоторые дополнения и примеры кода, которые могут быть вам полезны - я недавно обновил этот текст в сообщениях: https://authguidance.com/2017/09/26/basicspa-oauthworkflow/

Answer 2

Вы уже связали ссылки, которые дают понять, что вы не должны использовать неявное предоставление в SPA.Ваша путаница, похоже, исходит из вашего предположения, что поток предоставления кода требует использования секрета клиента, но это не так.SPA, как и любое приложение для браузера или устройства, является (должно быть) клиентом PUBLIC, и ему нельзя доверять с секретом.Поэтому он не использует секрет.Секрет клиента подходит ТОЛЬКО для использования с частными клиентами, то есть серверным кодом, вызывающим auth api.