Ответ 1

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

Маркер идентификатора предназначен для проверки клиенту, что пользователь аутентифицирован, и кто он в результате.

Когда клиент получает токен идентификатора, он обычно делает что-то вроде преобразования его в ClaimsIdentity и сохраняет его, например, используя файл cookie.

Идентификатор ID должен быть истек в этой точке использования (как и должно быть, поскольку он только что был выпущен). Но после этого он больше не используется, поэтому не имеет значения, истекает ли он, пока пользователь по-прежнему имеет активный сеанс. Клиент имеет требуемую информацию аутентификации и, в свою очередь, может выбрать свою собственную политику в отношении того, как долго длится сеанс до того, как пользователь снова войдет в систему.

Мое неправильное предположение, когда задавали вопрос, заключалось в том, что токен идентификатора и токен доступа должны использоваться вместе, и поэтому оба должны иметь действительные даты истечения срока действия. Это неверно по различным причинам:

• Идентификаторы ID предназначены только для аутентификации Клиенту (как описано выше).
• Доступ к токенам не имеет ничего общего с Клиентами. Они предназначены для доступа к ресурсам, и клиент обрабатывает их только в том случае, если в свою очередь необходимо вызвать ресурс.
• Что-то вроде автономного приложения MVC или WebForms требует только токена ID. Если он не вызывает внешний ресурс, доступ к нему невозможен, поэтому нет токена доступа.

Ответ 2

Мне приходилось копаться в этом по моим собственным причинам и писать, поэтому я опубликую то, что я узнал здесь...

Во-первых, я отвечу на вопрос, рискуя заявить очевидное: токен ID не может быть доверен, и его содержимое должно быть проигнорировано, если текущее время больше, чем истекшее время. В ответе на вопросника указано, что после первоначальной аутентификации пользователя идентификатор ID не используется снова. Однако, поскольку идентификатор ID подписывается провайдером идентификации, он, безусловно, может быть полезен в любое время, чтобы дать возможность надежно определить, кто является пользователем других сервисов, которые приложение может использовать. Использование простого идентификатора пользователя или адреса электронной почты не является надежным, поскольку его можно легко подделать (любой может отправить адрес электронной почты или идентификатор пользователя), но поскольку токен идентификатора OIDC подписан сервером авторизации (который также обычно имеет преимущество будучи третьей стороной), он не может быть подделан и является гораздо более надежным механизмом аутентификации.

Например, мобильное приложение может захотеть указать серверную службу, которой пользуется пользователь, и это может потребоваться после краткого периода после первоначальной аутентификации, после чего идентификатор ID истек, и, следовательно, не может использоваться для надежной аутентификации пользователя.

Таким образом, как и токен доступа (используемый для авторизации - указать, какие разрешения у пользователя есть), можно обновить, может обновить токен идентификатора (используется для аутентификации - указать, кто является пользователем)? Согласно спецификации OIDC, ответ не очевиден. В OIDC/OAuth есть три "потока" для получения токенов, потока кода авторизации, неявного потока и гибридного потока (который я пропущу ниже, потому что это вариант двух других).

Для неявного потока в OIDC/OAuth вы запрашиваете токен идентификатора в конечной точке авторизации, перенаправляя пользователя в браузере конечной точке авторизации и включая id_token как значение параметра запроса response_type. Ответ на неявный поток успешной проверки подлинности НЕОБХОДИМО включить id_token.

Для потока кода аутентификации клиент указывает code как значение параметра запроса response_type при перенаправлении пользователя на конечная точка авторизации. Успешный ответ включает код авторизации. Клиентский клиент делает запрос к конечной точке маркера с кодом авторизации и, согласно OIDC Core Section 3.1.3.3 Успешный ответ на токен, ответ ДОЛЖЕН включать токен идентификатора.

Итак, для любого потока, как вы сначала получаете токен идентификатора, но как его обновить? OIDC Раздел 12: Использование токенов обновления содержит следующее выражение об ответе на токен обновления:

После успешной проверки токена обновления тело ответа является ответом маркера в разделе 3.1.3.3, за исключением того, что может не содержать id_token.

Он может не содержать токен идентификатора, и поскольку нет указаний, чтобы заставить его включать токен идентификатора, вы должны предположить, что ответ не будет содержать токена идентификатора. Таким образом, технически нет определенного способа "обновить" токен идентификатора, используя токен обновления. Таким образом, единственный способ получить новый токен идентификатора - повторная авторизация/аутентификация пользователя путем перенаправления пользователя на конечную точку авторизации и запуск потока неявного потока или кода аутентификации, как описано выше. Спецификация OIDC добавляет параметр запроса prompt в запрос авторизации чтобы клиент мог запросить, чтобы сервер авторизации не запрашивал у пользователя какой-либо пользовательский интерфейс, но перенаправление все еще должно произойти.

Ответ 3

Это одно и то же намерение: вы не можете использовать id_token по истечении срока его действия. Основное различие заключается в том, что id_token - это структура данных, и вам не нужно будет вызывать какие-либо серверы или конечные точки, поскольку информация кодируется самим токеном. Обычный access_token обычно является непрозрачным артефактом (например, GUID).

Пользователь id_token должен всегда проверять его достоверность.

Я не на 100% знаком с IS, но я бы предположил, что это поле для удобства. Вы всегда должны проверять заявку exp.

Истечение срока действия - это только одна из валидаций. id_token также имеют цифровую подпись, и это также проверка, которую вы должны выполнять.

Ответ 4

Я хотел опубликовать этот ответ в качестве комментария, но, поскольку я не был очень активен в StackOverflow, я предполагаю, что я отправляю его как альтернативный ответ.

Вы также используете id_token как id_token_hint при попытке входа пользователя из сеанса http://openid.net/specs/openid-connect-session-1_0.html. Я, честно говоря, не думаю, что это действительно имеет значение, если срок действия id_token истек, поскольку вы беспокоитесь только о том, чтобы вывести конкретного пользователя.

Ответ 5

Обновление токена означает, что вы можете использовать его снова для запроса чего-либо с сервера авторизации (в этом случае OP - поставщик OpenID-Connect) ДАЖЕ, КОГДА ПОЛЬЗОВАТЕЛЯ НЕ ДОПУСКАЕТСЯ. Обычно вы разрешаете это только для ограниченных ресурсов и только после того, как пользователь вошел в систему и прошел аутентификацию хотя бы один раз. Световые жетоны сами по себе также должны быть ограничены во времени.

В OIDC неявный поток вы вызываете конечную точку авторизации,
и получить идентификатор ID в ответе вместе со всеми областями и в них все данные претензии.
Последующие вызовы API должны выполняться с помощью потока кода.
Неявный поток предназначен для использования только для javascript или только для браузера. Не приложение, которое взаимодействует с сервером.
Поэтому, даже если бы был способ "обновить" этот токен, вам не следует - разумная защита - позволить ему жить слишком долго. Он будет украден и повторно использован неавторизованными пользователями, олицетворяющими идентификатор. Вы должны принудительно ввести новый логин для этого.

В потоке кода вы вызываете конечную точку авторизации OP и получаете код авторизации (также называемый токеном авторизации или короткий код авторизации). Это должно истечь аналогично id_token, которое вы получили в неявном потоке, по тем же причинам и не может и не должно возобновляться.

Пользовательский интерфейс или приложение затем вызывают конечную точку OP Token и получают (иногда после того, как пользователь дает согласие через пользовательский интерфейс, чтобы разрешить использование принадлежащих им ресурсов на OP-сервере):

• Идентификатор id_token для аутентификации - который никогда не должен использоваться повторно в вызовах сервера, кроме как подсказка во время выхода из системы, когда его срок действия больше не важен, и поэтому по причинам, указанным выше, должно быть разрешено истекать и никогда не быть обновилась.
• Access_token - который позже при вызове API может быть предоставлен конечной точке OP UserInfo. Это вернет претензии, и API может разрешить соответствующим образом.

Вы можете обновить этот access_token, так как он сообщает API только о том, что утверждает пользователь, и о том, какие ресурсы (по областям и каждой области претензий) пользователь согласился дать вам. Как объяснялось выше, это разрешает доступ даже после того, как пользователь больше не войдет в систему. Конечно, вы никогда не хотите, чтобы id_token обновлялся, потому что вы не хотите разрешать олицетворение без входа в систему.

Ответ 6

Если я правильно понял, согласно this и OpenID Connect Core 1.0 spec, сам токен идентификатора может храниться в кукисах как механизм для сохранения сеансов и отправляться с каждым запросом на проверку подлинности для Клиента. Затем клиент может проверить токен идентификатора либо локально, либо через конечную точку верификатора поставщика (если предоставлено как Google). Если токен истек, он должен сделать еще один запрос auth, за исключением этого времени с prompt=none в параметре URL. Также не забудьте отправить токен с истекшим ID в параметре id_token_hint, в противном случае поставщик может вернуть ошибку.

Итак, для Идентификатора токена кажется естественным, но prompt=none гарантирует, что новый токен идентификатора может быть получен гладко без вмешательства пользователя (если, конечно, пользователь не вышел из этого OpenID).

Ответ 7

TL;DR;

Проверяйте токен идентификатора, прежде чем доверять его словам.

Подробнее

Какова цель истечения срока действия токена ID в OpenID Connect?

Цель состоит в том, чтобы разрешить клиенту проверять токен идентификатора, а клиент должен проверить токен ID перед операциями, использующими информацию маркера ID.

От спецификацию неявного потока OpenID:

Если какая-либо из процедур проверки, определенных в этом документе, терпит неудачу, любые операции, требующие неверной проверки достоверности, ДОЛЖНЫ быть прерваны, а информация, которая не была подтверждена, НЕ ДОЛЖНА использоваться.

Чтобы подтвердить это, Документация Google OpenID Connect говорит об удостоверении маркера ID:

Одна вещь, которая делает значки ID полезными, - это тот факт, что вы можете передавать их вокруг разных компонентов вашего приложения. Эти компоненты могут использовать маркер ID как легкий механизм аутентификации, аутентифицирующий приложение и пользователя. Но прежде чем вы сможете использовать информацию в токере ID или полагаться на нее как на подтверждение аутентификации пользователя, вы должны подтвердить ее.

Итак, если наше клиентское приложение примет какое-то действие на основе содержимого токена ID, мы должны снова проверить токен ID.