У OpenID Connect токен доступу має термін дії. Для потоку коду авторизації це зазвичай короткий термін (наприклад, 20 хвилин), після чого ви використовуєте маркер оновлення для запиту нового маркера доступу.

ID лексем також має час закінчення терміну дії. Моє питання полягає в тому, що в цьому полягає?

Будь-який час закінчення терміну дії ідентифікатора, менший за час закінчення терміну оновлення, означатиме, що у вас з часом буде прострочений маркер ідентифікатора, але дійсний маркер доступу.

Отже, ви маєте намір:

• дати вашому ідентифікатору термін дії, який перевищує термін дії маркера оновлення, або
• встановіть для нього такий самий термін дії, що і маркер доступу, і вживайте певних дій (що?), коли термін його дії закінчується, або
• просто споживайте маркер ідентифікатора у своєму клієнті при отриманні, а потім ігноруйте час закінчення терміну дії після цього?

Специфікація OpenID Connect просто говорить, що під час перевірки маркера ідентифікатора,

"The current time MUST be before the time represented by the exp Claim."

який (можливо) підтримує третій варіант вище.

РЕДАГУВАТИ

Оскільки OpenID Connect базується на OAuth2, відповідь на додаткове запитання нижче можна знайти в специфікації OAuth2, яка говорить:

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

Пов'язане питання полягає в тому, що коли ви обмінюєтеся кодом авторизації на маркери, ця ж специфікація говорить, що ви можете отримати відповідь, таку як:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

Але до чого в цьому випадку відноситься "expires_in"? Маркер доступу, маркер оновлення або маркер ідентифікатора?

(Для інформації IdentityServer3 встановлює це як час закінчення терміну дії маркера доступу).

Я відповідаю на власне запитання, оскільки виявив, що деякі припущення, що стоять за моїм запитанням, були неправильними, тому їх тут легше пояснити, а не переписувати запитання.

Ідентифікаційний маркер призначений для того, щоб довести Клієнту, що користувач пройшов автентифікацію, і ким вони є в результаті.

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

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

Моє неправильне припущення, ставлячи запитання, полягало в тому, що маркер ідентифікатора та маркер доступу повинні використовуватися разом, і тому обидва повинні мати дійсні дати закінчення терміну дії. Це неправильно з різних причин:

• Токени ID призначені лише для автентифікації клієнту (як описано вище).
• Токени доступу не мають нічого спільного з клієнтами. Вони призначені для доступу до ресурсів, і Клієнт обробляє їх лише в тому випадку, якщо йому в свою чергу потрібно викликати ресурс.
• Щось на зразок автономної програми MVC або WebForms потрібен лише маркер ідентифікатора. Якщо він не викликає зовнішній ресурс, немає до чого надати доступ, тому немає і маркера доступу.

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

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

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

Отже, подібно до того, як можна оновити маркер доступу (який використовується для авторизації - вказуючи, які дозволи має користувач), чи можете ви оновити маркер ідентифікатора (використовується для автентифікації - вказуючи, хто такий користувач)? Відповідно до специфікації OIDC, відповідь не очевидна. В OIDC / OAuth є три "потоки" для отримання токенів, потік коду авторизації, неявний потік та гібридний потік (який я пропустити нижче, оскільки це варіант двох інших).

Для неявного потоку в OIDC / OAuth ви запитуєте маркер ідентифікатора в кінцевій точці авторизації, перенаправляючи користувача в браузері на кінцеву точку авторизації та включаючи id_tokenяк значення response_typeпараметра запиту. Відповідь на неявний потік успішної автентифікації ПОТРІБНА включати id_token.

Для потоку коду автентифікації клієнт визначає codeяк значення response_typeпараметра запиту при перенаправленні користувача на кінцеву точку авторизації. Успішна відповідь включає код авторизації. Клієнтський клієнт робить запит до кінцевої точки маркера з кодом авторизації та, відповідно до Розділу 3.1.3.3 Основного OIDC Успішна відповідь маркера, відповідь ПОВИНЕН включати маркер ідентифікатора .

Отже, для будь-якого потоку спочатку ви отримуєте маркер ідентифікатора, але як його оновити? Розділ 12 OIDC: Використання оновлювальних токенів містить таке твердження щодо відповіді оновленого маркера:

Після успішної перевірки токена оновлення, тілом відповіді є відповідь маркера з розділу 3.1.3.3, за винятком того, що він може не містити id_token .

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

Якщо я правильно розумію, відповідно до цього та специфікації OpenID Connect Core 1.0 , сам маркер ідентифікатора може зберігатись у файлах cookie як механізм збереження сеансів та надсилати клієнту з кожним запитом, що вимагає автентифікації. Потім Клієнт може перевірити маркер ідентифікатора або локально, або через кінцеву точку верифікатора Постачальника (якщо надається, як це робить Google ). Якщо термін дії маркера закінчився, він повинен зробити ще один запит автентифікації, за винятком цього разу з prompt=noneпараметром URL. Також переконайтеся, що в параметрі надіслано маркер ідентифікатора із закінченим терміном дії id_token_hint, інакше Постачальник може повернути помилку.

Отже, здається природним, що термін дії маркера ID закінчується, але prompt=noneгарантує, що новий маркер ідентифікатора можна буде отримати плавно, без втручання користувача (якщо, звичайно, користувач не вийде з цього OpenID).

Це той самий намір: ви не можете використовувати id_tokenпісля закінчення терміну його дії. Головна відмінність полягає в тому, що an id_token- це структура даних, і вам не потрібно буде викликати будь-які сервери чи кінцеві точки, оскільки інформація кодується в самому маркері. Зазвичай звичайний access_token- це непрозорий артефакт (як GUID).

Споживач id_tokenсусла повинен завжди перевіряти його (часову) дійсність.

Я не на 100% знайомий з ІС, але, мабуть, це поле зручності. Завжди слід перевіряти expпретензію.

Термін дії - лише одне з підтверджень. id_tokens також мають цифровий підпис, і це також перевірка, яку ви повинні виконати.

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

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

У потоці коду ви викликаєте кінцеву точку авторизації OP і отримуєте код авторизації (також званий маркером авторизації, або коротше authcode). Термін дії цього терміну дії закінчується подібно до id_token, який ви отримали в неявному потоці, з тих самих причин, і його не можна і не слід поновлювати.

Потім ваш користувальницький інтерфейс або програма викликає кінцеву точку токена OP і отримує (іноді після подальшої згоди користувача через інтерфейс, щоб дозволити використання власних ресурсів на сервері OP):

• Ідентифікатор id_token для автентифікації - який більше ніколи не слід використовувати у дзвінках сервера, за винятком підказки під час виходу, коли термін його дії вже не важливий, і тому, з наведених вище причин, слід дати термін його дії і ніколи не оновлювати.
• Tok_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термін дії закінчився на даний момент, оскільки вас турбує лише вихід певного користувача.

TLDR;

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

Детальніше

Що таке час закінчення терміну дії маркера ID у OpenID Connect?

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

З специфікації неявного потоку OpenID :

Якщо будь-яка з процедур перевірки, визначених у цьому документі, не вдається, будь-які операції, що вимагають інформації, яка не змогла правильно перевірити, ПОВИННІ бути припинені, а інформація, яка не вдалася перевірити, НЕ МОЖЕ використовуватися.

На підтвердження цього в документації Google OpenID Connect говориться про перевірку токена ідентифікатора:

Одне, що робить токени ID корисними, це той факт, що ви можете передавати їх по різних компонентах вашого додатка. Ці компоненти можуть використовувати маркер ідентифікатора як полегшений механізм автентифікації для автентифікації програми та користувача. Але перш ніж ви зможете використовувати інформацію в маркері ідентифікатора або покладатися на неї як твердження, що користувач пройшов автентифікацію, ви повинні перевірити її.

Отже, якщо наша клієнтська програма збирається виконати певні дії на основі вмісту маркера ідентифікатора, то ми повинні знову перевірити маркер ідентифікатора.