Открыть ID Подключить доступ к управлению сеансом / обновить маркер против iFrame сессии

Question

У нас есть веб-приложение, в котором мы разрешаем пользователям входить в приложение с помощью любого поставщика Open ID (например, Okta, Google, Facebook и т. Д.).Мы хотим реализовать правильную методологию / рабочий процесс Open ID Connect, чтобы пользователь вошел на сайт.

Существующая реализация рассматривает истечение срока действия токена доступа, а затем, если он близок к истечению срока действия, использует токен обновления, чтобы получить новый токен доступа для входа пользователя в систему. Я чувствую, что это неправильно.Когда пользователь входит в веб-приложение, Identity Token используется для аутентификации личности пользователя с использованием рабочего процесса кода авторизации.Токен доступа и токен обновления хранятся на стороне сервера.Периодически токен обновления используется для получения новых токенов доступа, позволяющих пользователю войти на сайт.Я считаю, что это угроза безопасности, потому что -

Представьте, если пользователь вошел в свою учетную запись OP в браузере.Он открывает Sky и напрямую вошел в MP, потому что он уже вошел в MP.Затем он в отдельной вкладке выходит из своей учетной записи OP.Он будет продолжать входить в MP в течение нескольких дней на основе этого механизма Обновить токен / токен доступа!Разве это не угроза безопасности?

Если вы чувствуете, что правильный путь для этого - использовать Управление сессиями с использованием фреймов, как это предписано здесь на OIDC - https://openid.net/specs/openid-connect-session-1_0.html

Для получения дополнительной информации,когда пользователь входит в наше WebApp, мы извлекаем данные из конечной точки UserInfo OP, чтобы создать профиль в нашем WebApp и устанавливать разрешения / роли в нашем приложении на основе данных, передаваемых из конечной точки UserInfo OP.Мы продолжаем делать это периодически.Для этой цели я чувствую, что использование токена доступа (и использование токена обновления для получения нового токена доступа) для доступа к API UserInfo является правильным, поскольку оно соответствует концепции OAuth 2.0 по защите / авторизации конечных точек API / ресурсов с использованием токенов доступа.

Я хочу знать, действительно ли это правильный способ управления входом пользователя в систему при поддержке Open ID Connect.

Answer 1

Я думаю, что первый вопрос заключается в том, хотите ли вы связать время жизни сеанса единого входа поставщика OpenID Connect с сеансом вашего приложения.Вы просто хотите аутентифицировать пользователя, используя его сервис OpenID Connect.Если я выйду из Google, я ожидаю выхода из GMail, но не из стороннего приложения, которое использовало Google для аутентификации.Хотели бы вы также реализовать единый выход?

Но если бы я хотел выйти из системы при выходе из провайдера OpenID Connect, я бы реализовал Управление сеансом OpenID Connect .При использовании iframes и файлов cookie следует помнить одну вещь: в браузерах есть опция «Блокировать сторонние файлы cookie» (так ее называет Chrome), по умолчанию она отключена, но, насколько я знаю,при включении он отключает функцию единого входа.

Я не уверен, почему вы периодически запрашиваете конечную точку userinfo.Если вы просто хотите проверить, действителен ли токен доступа, вы также можете использовать конечную точку самоанализа токена .

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