Коли ви читаєте специфікацію по OpenID Connect. ви можете відчувати досить неприємні почуття від легкої іспуганни до цілковитого розчарування. Все це відбувається тому, що вони написані на "сухому" мовою специфікації, і здебільшого вони описують граничні випадки, винятки і т.д. Проте, коли ви переводите їх нормальною людською мовою і перемикаєтеся на конкретні випадки, все стає досить очевидно. Отже, давайте приступимо! (Ремарочка: велика частина тексту збігається з початковим пропозицією, написаним Девідом Рекордоном. В основному, мої правки торкнулися лише деякі з імен параметрів та інші дрібниці)
Створення запиту OpenID Connect
Для того, щоб клієнт міг зробити OpenID Connect запит, він повинен мати наступну інформацію про сервер:
Побудова клієнтом запиту OAuth 2.0, для отримання токена.
Незважаючи на те, що попередня реєстрація вашого клієнта на сервері може бути не обов'язкова, цілком ймовірно, що сервера матимуть різні обмеження і вимоги до клієнтів для запитів до інформації користувачів.
Отримання OpenID Connect відповіді
Перша частина - це Base64url. закодований в нотації JSON і описує алгоритм і тип токена:
Друга частина - це Base64url, закодований в нотації JSON:
Третю частину сервер отримав слід чином:
Доступ до інформації про користувачів (опціонально)
Сервер за потребою може додати додаткові дані в цей відповідь (наприклад такі як переносяться контакти) поки вони не змінюють зарезервовані ключі OpenID Connect. (Примітка: є більш чітко визначені ключі, але для стислості, я опущу їх опис.)
Відкриття (опціонально)
Відповідь є об'єктом JSON, який включає в себе кінцеву точку і іншу інформацію.
наприклад:
Незареєстровані клієнти і динамічна реєстрація (опціонально)
Перед тим, як відповісти на запити, сервер повинен перевірити, чи зареєстрований URL коллбек за межами цього потоку OpenID. Якщо так, сервер відправить інформацію з реакцією на помилку. Сервера необхідно буде розробити політику для обробки таких випадків, коли передані redirect_uri були попередньо зареєстровані розробником клієнта, при запитах динамічної реєстрації. Така поведінка може означати, наприклад, що нові запити динамічної реєстрацій з цими redirect_uri приведуть до помилки, але запити з використанням вже здійсненої динамічної реєстрацій продовжать працювати, поки не втратять актуальності.
Для забезпечення динамічної асоціації, сервер включає в себе наступні параметри відповіді JSON:
- client_id - ідентифікатор клієнта. Це значення може змінитися з кожним відповіддю, на запит серверу.
- client_secret - ключ клієнта. Він обов'язково зміниться з кожним відповіддю.
- expires_at - кількість секунд від 1970-01-01T0: 0: 0Z згідно UTC, поки client_id і client_secret не застаріє або 0, якщо вони не мають терміну давності.
- registration_client_uri - uri для управління цими реєстраційними даними.
- registration_access_token - токен, який буде використовуватися для доступу до registration_client_uri.
Клієнту необхідно зберігати свої дані динамічної реєстрації для роботи з токенами сервера. Для кожної динамічної реєстрації клієнту необхідно буде зберігати ідентифікатор клієнта, ключ клієнта, час закінчення, призначений для користувача URL, підтримувані потоки, а також API для користувача інформації. Час закінчення терміну слід зберігати як абсолютний час або мітку того, що реєстрація триватиме вічно.
Як бачите, основні процеси веб-клієнта OpenID Connect досить прості, і так само прості, як ті, які пропонувалися спочатку. У той же час, можуть бути використані додаткові функціональні можливості, наприклад запит конкретних наборів даних, а не набір за замовчуванням. Ці додаткові можливості доступні, коли вони необхідні і не перетворюють прості взаємодії в великі проблеми для клієнтів, з великим числом OpenID провайдерів.