OpenID Connect: правильный способ аутентификации токена пользователя ID или токена доступа? Обновить ID токены?

Question

В нашем веб-приложении (ASP.NET) мы используем OpenID Connect с потоком кода авторизации:

1. Пользователь перенаправляется к поставщику удостоверений (например, Azure AD), аутентифицируется,
2. Код авторизации размещен на странице нашего веб-приложения.
3. Наше веб-приложение затем получает токен обновления, токен идентификатора и токен доступа с сервера идентификации с помощью кода авторизации. Они хранятся на клиентах в виде файлов cookie (с флагом HttpOnly, установленным в значение true). Это делается для того, чтобы избежать зависимости от состояния сервера, в случае, если пользователь перенаправляется на другой веб-сервер с помощью балансировщика нагрузки.
4. Когда пользователь заходит на страницу, мы проверяем подпись и срок действия идентификатора токена идентификатора и проверяем заявление, которое мы используем для идентификации (например, адрес электронной почты или UPN) в базе данных пользователей в нашем приложении.

Это работает - за исключением того, что мы не можем обновить токен идентификатора, поэтому у пользователей истекает время ожидания через 1 час, что требует нового входа в систему. Согласно спецификациям OpenID Connect, при обновлении токенов с помощью конечной точки токена не все поставщики OpenID Connect будут предоставлять новый идентификатор токена.

Альтернативы, которые мы видим до сих пор:

1. Не используйте ID-токен вообще. Используйте токен доступа, чтобы запросить у конечной точки UserInfo требования пользователя и кэшировать его на сервере (при пропадании кэша, например, если он перенаправлен на другой веб-сервер - просто используйте предоставленный токен доступа из файла cookie, чтобы запросить UserInfo снова). Поскольку токены доступа могут быть обновлены, это, вероятно, будет работать нормально.
   • Плюсы: мы получаем обновленный токен, который проверяется сервером.
   • Минусы: не все претензии (например, aud и iss) предоставляются конечной точкой UserInfo, по крайней мере для Azure AD.
2. Не проверяйте срок действия идентификационного токена, просто он не старше, например, например. 12 часов.
   • Плюсы: просто, не требует больших усилий, чтобы изменить текущее поведение. Имеет все претензии, которые мы также имеем сегодня.
   • Минусы: может ли быть угроза безопасности? Комментарии?

Так каков рекомендуемый способ сохранения логина пользователя в течение более длительного периода времени? Будет ли использование токена доступа с конечной точкой UserInfo подходящим решением?

Answer 1

Зависит от того, как используется токен Identity. Обычно это только для клиента. Это позволяет клиенту аутентифицировать пользователя на основе обязательной заявки sub. Не следует использовать для авторизации. Вот для чего нужен токен доступа.

В гибридном потоке (code + id_token) вы можете проверить подлинность пользователя перед запросом других токенов. В этом случае маленький токен является наиболее эффективным.

В потоке кода авторизации (коде) вам все равно придется запрашивать токены, используя код. Теперь это зависит от информации в id_token. Если id_token не содержит утверждений профиля, вам потребуется запросить информацию у конечной точки UserInfo.

Для доступа к конечной точке UserInfo вам нужен токен доступа. Отсутствующие утверждения aud и iss могут не представлять проблемы, поскольку вы запрашиваете токен у самого органа. Сдается мне, что издатель и аудитория известны на тот момент.

Обратите внимание, что id_token не используется для авторизации, поэтому не должно быть угрозы безопасности. Даже когда id_token используется совместно с ресурсами.

Спецификации требуют проверки полученного токена, как описано. Но когда вы не получаете новый id_token, зачем снова проверять текущий? Возможно, он не обновлен, но он уже подтвержден.

Так что ИМО оба варианта хороши, хотя я думаю, что первый вариант более распространен. Вероятно, что id_token отбрасывается после использования. Поскольку токен доступа используется для доступа к ресурсам (включая конечную точку UserInfo), а токен обновления - для обновления токена доступа.

Одно замечание, согласие пользователя используется в качестве фильтра. Если пользователь не дает согласия на информацию профиля, он вообще не будет доступен.

Answer 2

Сначала вам нужно понять назначение каждого токена. Идентификационный токен предназначен для использования клиентом (приложением). Он содержит утверждения, которые вы можете проверить для аутентификации конечного пользователя (Аутентификация).

Маркер доступа существует для авторизации. Он предназначен для использования с защищенным ресурсом (например: - API, защищенный токенами OAuth 2.0). Когда API получает токен, он должен проверить его и предоставить доступ.

Обновить токен, чтобы обновить токен доступа. Теперь OpenID Connect, являющийся расширением OAuth 2.0, позволяет использовать токен обновления. Но, как вы выяснили, идентификационный токен может обновляться или не обновляться. Я лично видел, что Auzre AD не обновляет идентификационный токен.

Лучшее решение - использовать сеанс между интерфейсом и сервером. Вы устанавливаете этот сеанс после проверки токенов из запроса токена. Хранилище сеанса может содержать токен доступа, который был первоначально отправлен. Наряду с этим, сохраните маркер обновления. Вы можете просто проверить идентификационный токен и отказаться от него (учитывая, что вы храните всю необходимую информацию для сеанса). Убедитесь, что этот сеанс HttpOnly и Secure (только Https). Срок действия сеанса может быть равен сроку действия токена доступа.

По истечении срока действия маркера доступа вы можете использовать токен обновления для получения нового токена. И всякий раз, когда вы хотите, ваш бэкэнд может добавлять токен доступа к запросам API от бэкэнда. Таким образом, вы никогда не выставляете токен доступа и не обновляете токен для внешнего интерфейса.