Решение / архитектура единого входа (SSO) для одностраничного приложения (SPA)

Я уже некоторое время изучаю решение SSO для SPA. Существует множество решений с небольшими различиями, хотя я также обнаружил, что не все имеют одинаковое понимание единого входа, и не так много устоявшихся шаблонов единого входа для SPA. Таким образом, я не спрашиваю о детальном дизайне / архитектуре, а просто пытаюсь увидеть, есть ли какие-либо общие практики по этой теме.

Что я имею в виду для SSO?

  1. Мы разрабатываем несколько новых SPA (также, возможно, мобильных и планшетных приложений), которые будут развернуты на разных серверах и в разных доменах.
  2. У нас также есть центральный IdP (authServer), где будут храниться все идентификаторы пользователя.
  3. После того, как я войду в SPA1 и нажму кнопку, которая приводит меня к SPA2 (или, возможно, SPA3, SPA4), мне не нужно вводить учетные данные пользователя, и я буду автоматически входить в систему.

Какая разница для СПА? (в отличие от обычного веб-приложения)

Я посмотрел на несколько решений, даже старые решения, такие как SAML(просто хочу получить представление о SSO..). Мой текущий кандидат - OpenId Connect, но затем я понял разницу для SPA, если мое понимание верно: в отличие от обычных веб-приложений, SPA обычно не имеет (или мы стараемся не иметь) бэкэнд-сервер. У SPA есть только сервер, обслуживающий статические страницы вместе со скриптами, таблицами стилей и изображениями.

Теперь возникает проблема:

OpenId Connect основан на типе предоставления кода авторизации OAuth2, что означает:

  1. Мне нужен внутренний прокси-подобный модуль для каждого SPA, если я хочу, чтобы он работал.
  2. Я использую другое решение для единого входа на стороне клиента, например, которое обеспечивает auth0
  3. Я не нашел другого решения / примеров

Мой вопрос:

Для пункта 1 выше, верно ли мое понимание? Что лучше, чтобы в SPA не было бэкэнд-кода, как в обычном веб-приложении?

Для вышеприведенного пункта 2 это похоже на решение, но как это существенно отличается от типа неявного предоставления OAuth2?

И есть ли другие решения (фреймворк, протокол и т. Д.), Которые я должен знать, но еще не исследовал?

Источник

2 ответа

Решение

В дополнение к базовому профилю клиента, который использует грант кода авторизации, OpenID Connect имеет неявный профиль клиента, который основан на гранте Implict из OAuth 2.0. Этот профиль позволяет доставлять токены напрямую клиентам в браузере /Javascript без участия сервера.

Источник

В настоящее время поток кода в сочетании с общим доступом к ресурсам между источниками (CORS) и ключом подтверждения обмена кодом (PKCE) также можно использовать для одностраничных приложений.

В черновике «OAuth 2.0 для браузерных приложений» подробно описаны текущие шаги, которые следует использовать для безопасного внедрения OAuth/OpenID Connect для SPA. В разд. 4, «Обзор» резюмируется текущая передовая практика:

В последние годы широкое распространение совместного использования ресурсов между источниками (CORS), которое допускает исключения из политики одного и того же источника, позволяет браузерным приложениям использовать поток кода авторизации OAuth 2.0 и выполнять запрос POST для обмена кодом авторизации на токен доступа в конечной точке токена. В этом потоке маркер доступа никогда не раскрывается в менее безопасном переднем канале. Кроме того, добавление PKCE в поток гарантирует, что даже если код авторизации будет перехвачен, злоумышленник не сможет его использовать.

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

Черновик резюмирует следующие ключевые моменты, которые следует учитывать при реализации OAuth/OpenID для SPA (или других общедоступных клиентов):

Браузерные приложения:

  • НЕОБХОДИМО использовать поток кода авторизации OAuth 2.0 с расширением PKCE при получении токена доступа.

  • ДОЛЖНЫ защитить себя от атак CSRF одним из следующих способов:

    • убедиться, что сервер авторизации поддерживает PKCE, или

    • с помощью параметра «состояние» OAuth 2.0 или параметра «nonce» OpenID Connect для переноса одноразовых токенов CSRF.

  • НЕОБХОДИМО зарегистрировать один или несколько URI перенаправления и использовать только точно зарегистрированные URI перенаправления в запросах на авторизацию.

Источник
Другие вопросы по тегам