Рекомендации по аутентификации OIDC в SPA
Одностраничные приложения (SPA) быстро становятся повсеместными, поскольку они обеспечивают гораздо лучший пользовательский опыт по сравнению с традиционными многостраничными приложениями. Однако, как это часто бывает при разработке приложений, хороший пользовательский опыт и безопасность не совпадают. В SPA также достоинства SPA достигаются за счет безопасности. Но так не должно быть. Создавая SPA с учетом ограничений безопасности SPA и следуя лучшим практикам, мы можем смягчить большинство проблем безопасности в SPA.
Эта статья посвящена исключительно передовым методам использования протокола OpenID Connect (OIDC) для аутентификации в SPA. Тем не менее, некоторые передовые методы применимы к SPA независимо от используемого протокола аутентификации.
Управление сеансом
Во-первых, управление сессиями является минимальным требованием любого SPA. Однако это становится серьезной проблемой безопасности в SPA, поскольку хранилище на стороне клиента в браузере открыто для внешнего мира.
Большинство разработчиков предпочитают хранить информацию о сеансе, например маркеры доступа, в сеансе или локальном хранилище. Несмотря на то, что хранилище сеансов сравнительно более безопасно, чем локальное хранилище, ни одно из них не защищено от доступа стороннего кода. Это делает SPA уязвимыми для атак межсайтового скриптинга (XSS) и типосквотинга.
Одним из решений является использование файлов cookie только для http. Но это делает приложение уязвимым для атак с подделкой межсайтовых запросов (CSRF). Кроме того, если ваш сервер аутентификации и конечные точки API существуют в двух разных доменах, то файлы cookie только для http нельзя использовать вообще.
Распространенным решением является наличие выделенного бэкенда для вашего SPA, где вы можете хранить информацию о сеансе. Серверная часть будет выступать в качестве шлюза для всех ваших сетевых запросов. Однако это решение значительно усложняет вашу разработку.
Более работоспособным решением является использование веб-воркеров для хранения информации о сеансе. Веб-воркеры — это, по сути, фоновые потоки, которые имеют другой контекст просмотра. Так, сторонние коды не могут получить доступ к информации, хранящейся в памяти веб-воркеров. Это защищает приложение как от XSS-атак, так и от типосквотинга. Пакеты SPA SDK от Asgardeo позволяют разработчикам использовать веб-воркер в качестве хранилища, что значительно повышает безопасность приложений. Консоль и приложения Моя учетная запись Asgardeo используют этот метод для хранения информации о сеансе.
Используйте HTTPS в SPA
HTTPS предлагает безопасный канал между клиентским приложением и серверной частью за счет шифрования связи с использованием безопасности транспортного уровня (TLS). Это гарантирует, что токен доступа, используемый для запросов к защищенным конечным точкам, не будет украден злоумышленниками. Использование HTTP, который не шифрует связь, может сделать ваш SPA уязвимым для атак типа «человек посередине».
Предоставление кода авторизации вместо неявного предоставления
Несмотря на то, что неявный грант предназначался для клиентских приложений, он давно изжил себя. Поэтому всегда рекомендуется использовать предоставление кода авторизации вместо неявного предоставления в ваших SPA. На это есть несколько причин.
Начнем с того, что тип неявного предоставления возвращает маркер доступа в URL-адресе. Таким образом, в истории браузера создается постоянная запись токена доступа, что может привести к легкой компрометации токена доступа. Более того, современные браузеры хранят историю браузера в облаке. Это может перенести ваш токен доступа в облако и сделать его доступным на нескольких устройствах.
Предоставление авторизации намного безопаснее, поскольку в URL-адресе возвращается только код авторизации. Есть даже способы смягчить эту относительно незначительную проблему, и мы обсудим ее позже в статье. Затем SPA может использовать этот код для получения токена доступа. OIDC позволяет обмениваться токенами без секрета клиента для общедоступных клиентов, поэтому SPA также не нужно где-либо хранить секрет клиента.
Сообщение формы в режиме ответа на запрос
OIDC позволяет получить код авторизации двумя разными способами. Одним из них является популярный режим запроса, при котором код возвращается в качестве параметра запроса в URL-адресе перенаправления. Это имеет те же проблемы, что и неявное предоставление, поскольку код сохраняется в истории браузера.
Чтобы смягчить это, вы можете использовать режим публикации формы. Когда вы используете режим публикации формы, код отправляется в теле запроса на публикацию в конечную точку, указанную URL-адресом перенаправления. Это добавляет некоторую сложность вашему приложению, поскольку вам нужен бэкэнд для захвата отправленного кода авторизации. Но повышенная безопасность стоит затраченных усилий.
Обновить токены
Токены обновления позволяют SPA получать новый токен доступа по истечении срока его действия, не требуя вмешательства пользователя. Это обеспечивает лучший пользовательский интерфейс, но если токен обновления будет скомпрометирован, это может нанести больше вреда, чем компрометация токена доступа. Это связано с тем, что OIDC не требует проверки подлинности клиента при выдаче нового маркера доступа при представлении маркера обновления.
Это можно смягчить, гарантируя, что новый токен обновления выдается каждый раз, когда обновляется токен доступа. Это предотвращает повторные атаки. Кроме того, срок действия токена обновления должен быть коротким, чтобы значительно уменьшить масштаб ущерба, причиняемого атакой.
Используйте PKCE в SPA
PKCE расшифровывается как Proof Key for Code Exchange и является расширением предоставления кода авторизации. Это позволяет поставщику OIDC гарантировать, что сторона, запрашивающая токен доступа с использованием кода авторизации, является той же стороной, которая запрашивала код авторизации в первую очередь.
Это включает в себя отправку секретного ключа вместе с запросом кода авторизации и запросом токена доступа. Поставщик OIDC будет вести учет секретного ключа и выданного кода авторизации. Когда токен доступа запрашивается с кодом авторизации, провайдер проверяет, совпадает ли секретный ключ, прикрепленный к запросу токена, с секретным ключом, используемым для запроса кода авторизации. Если они совпадают, то выдается токен доступа.
Это предотвращает использование скомпрометированного кода авторизации для злонамеренного получения токена доступа. Это обеспечивает дополнительный уровень безопасности для общедоступных клиентов, которые не используют секрет клиента для аутентификации с помощью поставщика OIDC.
Используйте параметр состояния
Параметр состояния позволяет клиенту узнать, относится ли выданный ему код авторизации к отправленному им запросу авторизации. При формировании запроса на авторизацию клиент отправляет ключ в качестве значения параметра запроса состояния. Когда поставщик OIDC выдает код авторизации и перенаправляет браузер на настроенный URL-адрес перенаправления, параметр состояния также добавляется к URL-адресу. Проверяя, совпадает ли значение параметра состояния в перенаправленном URL-адресе со значением, отправленным во время запроса кода авторизации, клиент может убедиться, что полученный код соответствует отправленному им запросу.
Это важно для предотвращения атак с подменой кода и CSRF-атак.
Привязка токена
Привязки токенов обеспечивают дополнительную защиту защищенных конечных точек API. Вы можете использовать два типа привязок токенов — на основе файлов cookie и на основе сеанса единого входа.
При привязке токена на основе файлов cookie файл cookie только для http возвращается с кодом авторизации. Когда запрос маркера отправляется, этот файл cookie только для http также отправляется вместе с запросом. Затем поставщик OIDC проверит этот файл cookie и прикрепит его к маркеру доступа. После этого, если SPA требуется доступ к защищенным конечным точкам, ему необходимо создать как токен доступа, так и файл cookie только для http. Это защищает конечные точки API даже в случае утечки или кражи токена доступа.
При привязке токена на основе сеанса единого входа для каждого экземпляра браузера создаются разные токены доступа. Это гарантирует, что один и тот же токен доступа не будет использоваться несколькими экземплярами SPA в браузере.
Внедрение единого выхода в SPA
Если несколько SPA используют одного и того же поставщика OIDC, и пользователь выходит из одного из SPA, то пользователь должен выйти из всех SPA. Невыполнение этого требования позволит получить доступ к защищенным конечным точкам в других SPA, даже если пользователь завершил сеанс пользователя с поставщиком OIDC.
Это можно сделать используя iframe проверки сеанса. Запрашивая кадр проверки сеанса, SPA может узнать, изменилось ли состояние сеанса. Если он изменился, новый запрос кода авторизации может быть отправлен из iframe. Если возвращается код, это означает, что у пользователя есть активный сеанс в поставщике OIDC. Если код не возвращается, это означает, что пользователь вышел из системы. Таким образом, SPA должен вывести пользователя из приложения.
Следуя этим передовым методам обеспечения безопасности при разработке SPA, мы можем убедиться, что лучший пользовательский опыт, обеспечиваемый SPA, не достигается за счет безопасности. Но некоторые из этих лучших практик могут потребовать много времени на разработку, что значительно усложнит ваш проект. Вот почему пакеты SDK для SPA от Asgardeo включают в себя большинство из этих лучших практик, чтобы вы могли без особых усилий внедрить их в свои SPA. С компетентным сервером идентификации и набором безопасных SDK Asgardeo может сделать ваши SPA безопасными и надежными для использования. Итак, оформите заказ на Asgardeo, чтобы быстро разработать SPA без ущерба для безопасности.
Первоначально опубликовано на https://www.thearmchaircritic.org 13 декабря 2021 г.
