Мне пришлось копаться в этом по своим причинам и я написал это, поэтому я опубликую здесь то, что узнал ...
Во-первых, я отвечу на вопрос, рискуя заявить очевидное: токену идентификатора нельзя доверять, и его содержимое следует игнорировать, если текущее время больше, чем истекшее время. В ответе спрашивающего указано, что после первоначальной аутентификации пользователя ID-токен больше не используется. Однако, поскольку токен идентификатора подписан поставщиком удостоверений, он, безусловно, может быть полезен в любое время, чтобы дать возможность надежно определить, кто является пользователем, другим службам, которые может использовать приложение. Использование простого идентификатора пользователя или адреса электронной почты ненадежно потому что его можно легко подделать (любой может отправить адрес электронной почты или идентификатор пользователя), но поскольку токен идентификатора OIDC подписан сервером авторизации (который также обычно имеет то преимущество, что является третьей стороной), он не может быть подделан и является гораздо более надежный механизм аутентификации.
Например, мобильное приложение может захотеть сообщить серверной службе, кто пользователь, который использует приложение, и это может потребоваться по прошествии короткого периода после начальной аутентификации, когда истекает срок действия токена ID, и, таким образом, не может использоваться для надежной аутентификации пользователя.
Следовательно, точно так же, как токен доступа (используемый для авторизации - указывающий, какие разрешения есть у пользователя) может быть обновлен, можете ли вы обновить токен идентификатора (используемый для аутентификации - указав, кто является пользователем)? Согласно спецификации OIDC, ответ не очевиден. В OIDC / OAuth есть три «потока» для получения токенов: поток кода авторизации, неявный поток и гибридный поток (которые я пропущу ниже, потому что это вариант двух других).
Для неявного потока в OIDC / OAuth вы запрашиваете токен идентификатора в конечной точке авторизации, перенаправляя пользователя в браузере на конечную точку авторизации и включая id_token
значение response_type
параметра запроса. Неявный поток Успешного ответ аутентификации ОБЯЗАТЕЛЬНО должны включать id_token
.
Для потока кода аутентификации клиент указывает code
в качестве значения response_type
параметра запроса при перенаправлении пользователя на конечную точку авторизации. Успешный ответ включает код авторизации. Клиентский клиент делает запрос к конечной точке токена с кодом авторизации, и, согласно разделу 3.1.3.3 ядра OIDC «Успешный ответ токена», ответ ДОЛЖЕН включать в себя токен идентификатора .
Таким образом, для любого потока вы изначально получаете идентификатор ID Token, но как его обновить? В разделе 12 OIDC: Использование токенов обновления содержится следующее утверждение об ответе токена обновления:
После успешной проверки токена обновления телом ответа является ответ токена из раздела 3.1.3.3, за исключением того, что он может не содержать id_token .
Он может не содержать токен идентификатора, и, поскольку не указан способ заставить его включать токен идентификатора, вы должны предполагать, что ответ не будет содержать токен идентификатора. Таким образом, технически не существует определенного способа «обновить» токен ID с помощью токена обновления. Следовательно, единственный способ получить новый идентификатор ID - это повторно авторизовать / аутентифицировать пользователя, перенаправив пользователя на конечную точку авторизации и запустив неявный поток или поток кода аутентификации, как описано выше. Спецификация OIDC действительно добавляет prompt
параметр запроса к запросу авторизации, чтобы клиент мог запросить , чтобы сервер авторизации не предлагал пользователю какой-либо пользовательский интерфейс, но перенаправление все равно должно происходить.