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

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

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

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

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

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

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

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

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

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

Для неявного потока в OIDC / OAuth вы запрашиваете токен идентификатора в конечной точке авторизации, перенаправив пользователя в браузере на конечную точку авторизации и включив id_token в качестве значения параметра запроса response_type. ТРЕБУЕТСЯ неявный ответ успешной аутентификации потока для включения id_token.

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

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

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

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

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

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

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

Потребитель id_token должен всегда проверять его (временную) действительность.

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

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

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

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

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

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

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

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

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

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

TL; DR;

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

Подробнее

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

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

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

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

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

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

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

Просто поделись моим путешествием. Сейчас июнь 2021 года. Я пишу это, потому что наткнулся на сторонний бизнес по аутентификации. Я опытный программист, но новичок в безопасности. Другими словами, все стандарты, спецификации и терминология незнакомы, любой может победить меня в этой области. Простите, что не соблюдаю все условия.

Я пишу приложение Angular / Node, поэтому UI = Angular, API (сервер API) = Node / Express. Вместо того, чтобы создавать свою собственную аутентификацию по имени пользователя и паролю, я перехожу к сторонней аутентификации, позволяя им проверять подлинность того, что пользователи заявляют о себе. Вот два важных для меня путеводителя:

1. Angular Authentication с помощью веб-токенов JSON (JWT): полное руководство
2. Аутентификация Эйдзи на внутреннем сервере

Комбинируя №1 и angularx-social-login, я соединяю пользовательский интерфейс с Google, а затем присоединяю idToken к API, vola! Следуя № 2, используя API локальной библиотеки, можно проверить idToken, отлично!

Подождите, у idToken exp истекает через 1 час. Как мне его обновить?

Я понимаю, что все, что мне нужно, это аутентификация Google, мне все равно, какой стандарт и версию они используют, но, как и другие, я просто доверяю их аутентификации. Аутентификация - это в основном проверка того, кем они себя называют. Авторизация - это контроль доступа к тому, что и где пользователи могут делать / goto. Внутренний контроль доступа (позволяющий пользователям делать то, что) не предоставляется Google, они понятия не имеют об этом. Так что accessToken не должно быть в кадре. Верно?

Я провел несколько дней, изучая как обновить idToken, теперь пришел к выводу, что Google не рекомендует это и angularx-social-login предлагает способ. В № 2 Эйдзи четко заявил:

Следовательно, решение для моей ситуации

• использовать аутентификацию Google.
• создает собственные правила управления сеансом / тайм-аут в API после начальной проверки idToken для смягчения exp.
• желательно добавить данные сеанса в cookie с res.cookie("SESSIONID", myOwnID, {httpOnly:true, secure:true});

Для лучшей защиты Эйдзи также рекомендует Перекрестная защита аккаунтов. Надеюсь, это кому-то поможет!