Всем привет, мы снова встретились, я ваш друг Цюаньчжаньцзюнь.

Механизм аутентификации федеративных удостоверений OIDC

• фоновая концепция
• 1 протокол аутентификации личности OIDC
• 2. Внедрение единого входа на основе OIDC.
• • 2.1 Единый вход
  • • 2.1.1 Процесс
    • 2.1.2 Интерфейсы, связанные с RP
    • 2.1.3 Интерфейсы, связанные с OP
  • 2.2 Единый выход из системы
  • • 2.2.1 Процесс
    • 2.2.2 RP необходимо предоставить при регистрации в OP
    • 2.2.3 Интерфейсы, связанные с RP
    • 2.2.4 Интерфейсы, связанные с ОП
  • 2.3 Непрерывный мониторинг
  • • 2.3.1 Процесс
    • 2.3.2 Интерфейсы, связанные с RP
    • 2.3.3 Интерфейсы, связанные с ОП
• 3. Интегрируйте сторонний вход (GitHub) в единый вход OIDC.
• • 3.1 Процесс
  • 3.2 Интерфейсы, связанные с RP
  • 3.3 Интерфейсы, связанные с ОП
• Справочная документация

фоновая концепция

Аутентификация Сертификация是指应用软件（Пользователи идентификационной информации）Используя какой-либо метод для подтверждения того, кто является пользователем текущего запроса.。Процесс аутентификации на основе пароляможно разбить на три этапа： (1) Сервер аутентификации (поставщик идентификационной информации) получает пароль учетной записи пользователя от клиента. (2) Сервер аутентификации сравнивает полученный пароль учетной записи с паролем учетной записи, сохраненным в базе данных, и после подтверждения его правильности генерирует идентификационную информацию пользователя. (3) Пользователь получает идентификационную информацию пользователя от поставщика.

• Когда поставщики и потребители могут совместно использовать базы данных,Когда вам не нужно взаимодействовать через границы сети и безопасности,Две роли слились воедино,Выполнение первых двух шагов подтвердит, кем является пользователь, запрашивающий в данный момент.,Так что подумайте только об одном вопросе：【Q1】Согласно чемупроцесс、Формат может быть безопасно и надежноПередайте учетную запись пользователя и пароль от клиента на сервер аутентификации.。
• Когда поставщики и потребители развертываются независимо,Когда взаимодействие должно происходить через границы сети и безопасности,Только после выполнения всех трех шагов пользователь может подтвердить, кем является пользователь, запрашивающий в данный момент.,Следовательно, за исключением [Q1],Есть еще один вопрос, который следует рассмотреть：【Q2】Согласно чемупроцесс、Формат может быть безопасно и надежноПередача идентификационной информации пользователя от поставщика пользователю。

Все методы, которые позволяют пользователю подтвердить, кто является текущим пользователем, можно вместе назватьМеханизм аутентификации,Прикладное программное обеспечение на основе его развертывания、роль、Сделайте конкретный выбор, исходя из проблем, с которыми вы сталкиваетесь.

• Решение для [Q1]: аутентификация по форме, HTTP Базовая аутентификация, HTTP Дайджест-аутентификация, HTTP MutualСертификация。ЭтоWebОбычно используется в приложенияхИдентификация на основе пароля. Механизм аутентификации.。
• 【Q2】Решение：OIDC、SAML 、WS-Federation、Windows AD。这些统называется联合身份Механизм аутентификации（Federated Authentication）,Обычно используется для реализации единого входа, входа третьего лица.

Единый вход (SSO) Single Sign В системе, состоящей из нескольких взаимодоверяющих приложений, пользователям достаточно один раз войти в систему в одном приложении, чтобы получить доступ ко всем приложениям в системе. Единый вход в узком смысле означает, что пользователи могут получить доступ ко всем приложениям в своей системе, войдя в систему один раз. Широкая концепция единого входа также охватывает сторонний вход в систему: ваше собственное приложение доверяет стороннему приложению, и пользователям достаточно один раз войти в стороннее приложение, чтобы получить доступ к своему собственному приложению. Единый вход в этой статье относится именно к его узкому понятию.

Вход третьего лица Пользователи используют существующие учетные записи сторонних приложений (IDP) для быстрой регистрации и входа в свои собственные приложения.

Авторизация Авторизация означает, что прикладное программное обеспечение (поставщик ресурсов) использует определенный метод для подтверждения того, какие операции пользователь разрешает стороннему приложению (пользователю ресурса) выполнять над своими защищаемыми ресурсами. Поскольку поставщик ресурсов и пользователь ресурсов представляют собой два независимо развернутых приложения и должны взаимодействовать через границы сети и безопасности, необходимо учитывать следующие проблемы: 【Q3】Согласно чемупроцесс、Формат может быть безопасно и надежноПередача решений об авторизации пользователей от пользователей ресурсов поставщикам ресурсов.。РешениеOAuth 2.0。

OAuth 2.0Это лицензионное соглашение,它оговоренный一套传递用户Авторизовать决策из标准процесс、Формат.принять этопроцессизпреимуществолежит в用户существовать享受第三方应用替自己操作из便利时,Нет необходимости сообщать им пароль своей учетной записи,Сторонние приложения используют кратковременный токен доступа.,Пользователи могут контролировать объем разрешений токена.,И токен может быть признан недействительным в любой момент. Конкретный процесс: пользователь информирует сервер авторизации (Центр пользователей QQ).,Разрешить клиентскому приложению (стороннему онлайн-приложению PS) (читать указанный альбом) в пределах разрешений, на которые оно соглашается.,Получите доступ к своим собственным ресурсам данных (фотографиям), сохраненным на сервере ресурсов (пространство QQ). очевидно,Сервер авторизации (Центр пользователей QQ) должен сначала аутентифицировать личность пользователя.,Токен доступа будет выдан клиентскому приложению (приложению PS).,С помощью этого токена доступа клиентское приложение может обращаться к ресурсам пользовательских данных (читать фотографии из указанного альбома) с сервера ресурсов (QQ Space).

OAuth 2.0 Терминология Resource Владелец: владелец ресурса, то есть пользователь. Клиент: клиентское приложение, пользователь ресурсов пользовательских данных, полагается на учетные данные авторизации для доступа к конкретным ресурсам данных пользователя, хранящимся на сервере ресурсов. AS：Authentication Сервер, сервер авторизации, — это сторона, которая имеет возможность аутентифицировать пользователей, выдавать токены доступа и пользуется доверием сервера ресурсов. RS：Resource Сервер, сервер ресурсов, поставщик ресурсов пользовательских данных.

Подробное объяснение протокола авторизации OAuth 2.0 (токен на предъявителя)

OAuth 2.0 Соединение с механизмами аутентификации （1）OAuth 2.0 предусматривает, что сервер авторизации должен аутентифицировать пользователей, но это всего лишь протокол авторизации. Ему не важно, как сервер авторизации выполняет аутентификацию (т. е. [Q1]). Сервер авторизации сам выбирает механизм аутентификации. Сервер авторизации может выбирать из механизмов аутентификации по паролю, таких как аутентификация по форме, базовая, дайджест, взаимная и т. д. Он также может выбрать механизм аутентификации без пароля или их комбинацию.

(2) С точки зрения реализации OAuth 2.0 можно использовать в качестве механизма аутентификации федеративных удостоверений, но он не подходит и вызовет некоторые проблемы.

потому что:

• Авторизация OAuth 2.0 относительно безопасна и надежна.
• Роль сервера авторизации имеет возможность и должна аутентифицировать пользователей и, по-видимому, является подходящим поставщиком идентификационной информации пользователя.
• Иногда клиентским приложениям также необходимо использовать идентификационную информацию пользователя.

Поэтому некоторые люди задавались вопросом, могут ли они использовать OAuth. Передаёт ли авторизация 2.0 идентификационную информацию пользователя с сервера авторизации клиентскому приложению? то есть используя OAuth Версия 2.0 решает проблему [Q2] и использует ее в качестве механизма федеративной аутентификации личности.

OAuth 2.0 одновременно предоставляет услуги аутентификации и авторизации пользователей для клиентских приложений. но,OAuth 2.0 предназначен для авторизации. Использование его непосредственно для аутентификации пользователя может вызвать некоторые проблемы.。Хотя провайдер（Github）Возможность решить данные проблемы, выполнив дополнительное проектирование самостоятельно.,Но когда дополнительные конструкции, принятые каждым поставщиком, несовместимы,Весь процесс больше не унифицирован и стандартизирован.,Это создаст ненужную нагрузку на пользователя. Так родился протокол OIDC.,В нем указан стандартный набор дополнительных конструкций.

OIDC（OpenID Connect) — протокол аутентификации личности, определяющий набор стандартных форматов для передачи информации об идентификации пользователя от сервера авторизации (поставщика удостоверений) клиентскому приложению (потребителю удостоверений).

1 протокол аутентификации личности OIDC

OIDC（OpenID Connect) рассказывает о том, как использовать OAuth. Сервер авторизации 2.0 предоставляет услуги аутентификации пользователей для клиентских приложений и передает соответствующую идентификационную информацию стандартному протоколу клиентского приложения. ОИДК = (Identity, Authentication) + OAuth 2.0. Поскольку он основан на OAuth 2.0,После создания службы OIDC,就同时拥有了Сертификацияи Авторизовать две функции。Официальный сайт

Краткое описание китайской версии:

• [Сертификация & Авторизация] 4. OIDC（OpenId Connect) аутентификация личности (основная часть)
• [Сертификация & Авторизация] 5. OIDC（OpenId Connect) Аутентификация личности (расширенная часть)
• Начало работы с протоколом OpenID Connect
• Официально сертифицированная библиотека реализации OIDC (C, C#, Java, JavaScript, Python, PHP, Ruby и т. д.)

Терминология ОИДК EU：End Пользователь: Пользователь-человек. RP：Relying Party , пользователь идентификационной информации пользователя (OAuth клиентское приложение 2.0). OP：OpenID Провайдер, поставщик идентификационной информации пользователя (OAuth 2.0), способный аутентифицировать пользователей. OP может быть как приложением в вашей системе (пользовательский центр), так и сторонним приложением (IDP). IDP：Identity Поставщик, поставщик удостоверений, когда OP является сторонним приложением, его обычно называют IDP.

OIDCизпреимуществолежит в：

1. Это позволяет аутентификации личности существовать как независимая служба.
2. Единый вход для доменных имен первого уровня можно легко реализовать (используйте сервер авторизации в качестве пользовательского центра с отдельным доменным именем первого уровня в вашей собственной системе).
3. Совместимость с OAuth 2.0、SAML、WS-Federation、Windows AD, код подтверждения по SMS и многие другие типы IDP легко интегрируются. Вход третьего лица (поставьте сервер авторизации как Вход третьего поставщик удостоверений лица для использования).
4. OIDC основан на OAuth. 2.0, авторизация может проходить одновременно в одном процессе (выдача доступа токен) и аутентификация (выдача идентификатора token）。
5. Относительно безопасный и надежный,Некоторые чувствительные интерфейсы требуют TLS.,кроме,Воспользуйтесь преимуществами механизмов безопасности JWT, JWS и JWE.,Позволяет подписывать, шифровать и проверять некоторую конфиденциальную информацию цифровой подписью.,Дальнейшее обеспечение безопасности на протяжении всего процесса аутентификации.

Пример

• Центр пользователя. Крупномасштабная система веб-приложений обычно имеет несколько доменных имен первого уровня, таких как A, B, C и т. д., и разделяет логику авторизации и логику, связанную с пользовательской информацией, в службу, называемую Центр пользователя (имя домена О), О не обрабатывает бизнес-логику.
• Единый вход: когда бизнес-приложениям, таким как A, B и C, необходимо войти в систему, запрос на вход пользователя перенаправляется в пользовательский центр O для обработки. Пользователям нужно войти в систему только один раз в O, и все A, B и C смогут получить к нему доступ. В настоящее время бизнес-приложения, такие как A, B и C, являются RP, а пользовательский центр O — OP.
• Обеспечение входа во внешний мир третьего лица Служить：Пользовательский центрOсторонние приложенияGпоставлять身份Сертификация Служить。в это время,Стороннее приложение G — RP,Центр пользователя O — это его IDP.
• Использовать внешний вход третьего лица Служить：Пользовательский центрOТакже может выступать в качестве посредника,Разрешить пользователям использовать существующий пароль учетной записи приложения G для входа в A, B и C. Поскольку G отвечает за аутентификацию пользователей,O получает информацию о пользователе от G,В это время O — RP,G — его IDP. Затем,Связать полученную информацию о пользователе с собственной системой учетных записей,Предоставьте информацию о пользователе A, B и C. в это время,Бизнес-приложения, такие как A, B и C, относятся к RP.,Пользовательский центр O — это OP.

2. Внедрение единого входа на основе OIDC.

в целом,SSOвключать Единый входи Единый вывести две функции. с участием Единый входиз标准文件是Основной протокол OIDC,с участием Единый выходизиз标准文件是OIDCиз三个расширенный протоколFront-Channel Logout、Back-Channel Logout、Session Management。

2.1 Единый вход

OP: поставщик OpenID, поставщик идентификационной информации пользователя, центр аутентификации пользователей в вашей системе, доменное имя: op.com. RP: Проверяющая сторона, пользователь идентификационной информации пользователя, бизнес-приложение в вашей собственной системе, имя домена: rp.com.

В этом примере используется всего 3 механизма аутентификации: (1) Так называемая [реализация на основе OIDC] означает, что RP, как идентификационный пользователь, использует механизм аутентификации OIDC для подтверждения того, кто является текущим пользователем. (2) В качестве сервера авторизации и поставщика удостоверений OP должен проверить личность пользователя. В этом примере используется механизм аутентификации формы. OAuth 2.0 не уточняется, ОП может выбирать сам, например, его можно заменить на Базовую, Дайджест и Взаимную аутентификацию. (3) В качестве сервера авторизации OP также должен проверить личность клиентского приложения (RP), то есть подтвердить, от какого клиентского приложения (RP) поступает текущий запрос. В этом примере используется базовый механизм аутентификации. OAuth В версии 2.0 перечислены два механизма аутентификации: базовая аутентификация и передача параметров тела запроса POST (аутентификация по форме попадает в эту категорию), но последний использовать не рекомендуется, позволяя серверу авторизации самостоятельно выбирать другие механизмы аутентификации. Поэтому альтернативными вариантами являются: дайджест и взаимная аутентификация.

В этом примере также используетсяМеханизм управления сеансом на основе файлов cookie, альтернативные варианты: на основе сеанса, на основе токена, на основе аутентификации.。

2.1.1 Процесс

1. Когда RP требует от пользователя входа в систему, позвольте пользователю выбрать метод входа в систему. Пользователь выбирает использование своей собственной системной учетной записи и пароля для входа в RP (то есть передает параметр iss=oidc_op), который равен. срабатывает при отправке формы. GET rp.com/login?iss=oidc_op,это будетOPиз Интерфейс авторизацииGET op.com/authorizationи Обязательные параметры组装成完整изURI,Возврат 303 Location=Этот URI, перенаправленный браузером.

2、OPИнтерфейс авторизацииGET op.com/authorizationОбнаружил, что пользователь не авторизован（не носит имяpyoidcизcookie）,Возврат 303,Перенаправление на страницу входа в ОП через браузер. Пользователь вводит пароль,Интерфейс проверки учетной записи и пароля OP запускается при отправке формы. POST op.com/user_pass/verify。 (1) Если пароль учетной записи неверен, вы все равно будете перенаправлены на страницу входа в OP. (2) Если пароль учетной записи верен, перенаправьте обратно в интерфейс авторизации OP (возврат 303). Location = Location из шага 1) и установите состояние сеанса OP (установите файл cookie с именем pyoidc).

3、Переносимость браузераcookieВведите еще разOPИнтерфейс авторизацииGET op.com/authorization,Нашел файл cookie pyoidc,После подтверждения правильности его значения,Считайте, что пользователь вошёл в систему,Итак, выполните логику авторизации,Выдать код авторизации,Возврат 303 Location=redirect_uri (то есть интерфейс перенаправления, предоставленный RP через параметр запроса redirect_uri на шаге 1), браузер перенаправляет на redirect_uri.

4. Интерфейс redirect_uri RP получает код авторизации, использует код авторизации в фоновом режиме для запроса токена доступа (токена доступа) и токена идентификации (токена идентификатора) из интерфейса токена OP, а также использует токен доступа для запроса сведений о пользователе. из интерфейса сведений о пользователе OP.

2.1.2 Интерфейсы, связанные с RP

1、GET rp.com/login?iss=oidc_op：Пользователь решает войти в систему, используя свою собственную системную учетную запись и пароль.（iss=oidc_op）,Этот интерфейс отвечает за сборку интерфейса авторизации OP и необходимых параметров в полный URI.,Перенаправление через браузер,Что возвращает:

HTTP/1.1 303 See Other
Location: http://op.com/authorization
?redirect_uri=http://rp.com/code_flow/oidc_op
&scope=openid+profile+email+address+phone
&response_type=code
&nonce=cdYrYNLv6wBHlBmZjWxvrQmmD
&state=DJOfvYDSDxaPzOKRoyaTaQWCoWywdeKU
&client_id=EqAfEpR492It

Параметры передачи:

• redirect_uri: требуется. После успешного входа пользователя в систему ОП возвращает код авторизации и другую информацию в интерфейс RP.
• Область: требуется. Запрашиваемые разрешения на ресурс должны включать openid, который указывает приложение для токена идентификатора.
• тип_ответа: требуется, какой тип OAuth вы хотите, чтобы ОП использовал? 2.0Авторизоватьпроцессответить,code代表Авторизовать码процесс。
• client_id: требуется, client_id, зарегистрированный RP с OP.
• состояние: рекомендуемая непрозрачная строка. Когда OP перенаправляет на redirect_uri, она будет возвращена RP как есть, чтобы предотвратить CSRF и XSRF. Поскольку OP вернет этот параметр как есть, значение состояния может быть привязано к URI, который последний раз просматривался пользователем перед входом в систему RP, чтобы пользователь мог быть перенаправлен обратно на последнюю просмотренную страницу после завершения входа в систему.
• nonce: необязательная непрозрачная строка. Когда OP возвращает токен идентификатора, токен идентификатора будет содержать это значение, чтобы уменьшить количество атак повторного воспроизведения.

2、GET rp.com/code_flow/oidc_op：Интерфейс перенаправления（Redirection Endpoint), то есть параметр redirect_uri в интерфейсе 1, нужно реализовать: （1）перениматьOP回传изcode（Авторизовать码）、stateи другая информация,使用Авторизовать码существовать后台КOPиз Интерфейс токенаPOST op.com/tokenЗапросить получениеaccess идентификатор токена token。в,Заголовок запросаAuthorizationполе пройденоBasicПередача ключевых словRPсуществоватьOP注册изclient_idиclient_secret。

POST op.com/token
Authorization: Basic cUZFeFZtQlE4blBZOjVjNWVkYjA2OTA2MTZjZGJkNGNmOWMwYjBlMjg3MWVkNjM2MzE2ZTliNjI1NWQzMDA2MDg3NGJm
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&redirect_uri=http://rp.com/code_flow/oidc_op
&client_id=qFExVmBQ8nPY
&state=DJOfvYDSDxaPzOKRoyaTaQWCoWywdeKU
&code=Z0FBQUFBQmVjdHFwR20wY0U5WnJ0MUxVQVhZUm1VR2UyeW14SHNLQjdxZS1fZkRhQkVkdkI0bmwyXzhDTlZ3NlVLUm51dGotRUV1TlVydG8wTjlMbEVNSjJ6ZkVnUjd4R3lsZG9pdkJNZUdRWTVkdlYzV1BEbndzUFZNWWxkY0dnVUVpaVRqaDBlaXh0dTZwbUJYQ2FmY0dabmxnY05tLVVWY2hlWXNueTM5ak5xMFdQSjgzaC1vVzhVTWsxWDZ5bWliVFRQM1IzbzR6d1dRb1RHOTF6RmI0QjFpWTdIdXNWQ0VUMjJ0cHdSRTV0UUlwWUdGMHVyUT0%3D

(2) Получите доступ, возвращаемый интерфейсом токена OP. идентификатор токена токен и другая информация. Используйте состояние, ключ подписи и другую информацию, предоставленную ОП, для проверки идентификатора. Подлинность токена. (3) Использовать доступ tokenсуществовать后台КOPиз Интерфейс сведений о пользователеGET op.com/userinfoотправить запрос,Получить данные пользователя。в Заголовок запросаAuthorizationИспользование поляBearerПередача ключевых словaccess token。

GET op.com/userinfo
Authorization: Bearer Z0FBQUFBQmVjdHFwcW1Xc08ybG9BaG5PRGNJSTR3alFjTjJEcEF4aVl3VDZCMW5OTmFhOXdZeUR2bm4tX2d5U0Y0Z0Y0T2tFMWFZQ2dTaG1MSmdjZjlrOHlHNml5SXQ5R2RqVGN5SE84WjNmSkFfZ3MycTZMZXlQYXd2Nm0wZXhiMVkzeVNORGtHRExIN2xYX0twbkJfVmg2Wks3bGwtOTVvbEV3ajZuQWVETVFDYm8tWlZTZC1SdjVNMHRJU3c2QlYtTFp0a2wtQkVBMWFwZDJqXzJmZkRVT1Fka2I2ck9nLWFWRzRTaGVHN0Y4ZkZobmNHZ0FCaz0=

(4) RP создает собственное состояние сеанса (устанавливает файл cookie, указывающий, что пользователь вошел в систему RP). (5) Найдите URI, привязанный к состоянию, и перенаправьте пользователя обратно на последнюю страницу, просмотренную перед входом в систему.

2.1.3 Интерфейсы, связанные с OP

1、POST op.com/registration：RPКOP进行注册изинтерфейс,ОП возвращает client_idиclient_secret в RP. 2、GET op.com/static/jwks.json：OPпоставлятьJWT签名秘钥изинтерфейс。 3、GET op.com/authorization：Интерфейс авторизации（Authorization Конечная точка), необходимо реализовать: （1）перенимать并проверятьRPсуществовать查询参数中传入изredirect_uri、scope、response_type、client_id、state、nonce。Если проверка не удалась,возвращатьсяРеакции на ошибки, указанные OIDC。（本例Воля这个带有查询参数из完整URIназываетсяauthz_uri,Будет использовано позже) (2) Проверьте, вошел ли пользователь в систему на OP (проверьте файл cookie с именем pyoidc). Если вы не вошли в систему,则重定КприезжатьOPСтраница входаGET op.com/login.html?authz_uri=...（существовать查询参数中传入authz_uri）；Если вы вошли в систему,Затем выполните логику авторизации,Объедините код авторизации и другие возвращаемые параметры с redirect_uri, предоставленным RP, чтобы сформировать полный URI.,Перенаправление через браузер,Что возвращает:

HTTP/1.1 303 See Other
Location: http://rp.com/code_flow/oidc_op
?state=DJOfvYDSDxaPzOKRoyaTaQWCoWywdeKU
&scope=openid+profile+email+address+phone
&code=Z0FBQUFBQmVjc2ExRTJvZmpGN1FNTERzV0NQOUVieHRHZUdLdUd5V0dvZUMzTzliS3hjeUVpVUpxN21GWWhhaTlvalVyblVOVXI2XzJVZG1vZlctNkRNZlpTanpFM2hVSzdKaWliSDUxX1RhcW5pUk9ScTRMNW1icUh6WlJGamxIWkJhbmFnakhxbUdTenJpZVowQ3dEbDh5c3Z1ZDBpOWFGSXBtMHBRSk1IUFdPTVBxUmtzUnEzVHFCWDlYMDhXUkItWXVWczkwT0Fjb1M1bktIalZCUUdSd2p3b2lnUGZYazhEODdYekhnRTJVdzZjRkR3U01SUT0%3D
&iss=http%3A%2F%2Fop.com
&client_id=EqAfEpR492It

Параметры передачи:

• состояние: вернуть состояние, переданное RP, как есть.
• код: код авторизации, выданный OP.
• область действия: разрешения на ресурсы, одобренные OP.
• iss: Эмитент кода авторизации, то есть доменное имя OP.
• client_id: объект выдачи кода авторизации, то есть client_id RP.

4、POST op.com/user_pass/verify：Интерфейс проверки учетной записи и пароля,Пользователь вводит пароль учетной записи на странице входа в ОП.,Этот интерфейс срабатывает при отправке формы. Его входным параметром является секрет аккаунта и authz_uri.,负责进行表单Сертификация： (1) Если пароль учетной записи неверен, он все равно будет перенаправлен обратно на страницу входа в OP. (2) Если пароль учетной записи правильный, создайте собственное состояние сеанса OP (установите файл cookie с именем pyoidc) и перенаправьте на authz_uri через браузер, то есть верните:

HTTP/1.1 303 See Other
Set-Cookie: pyoidc="1584580277|BEWREbvcxoKRTD/6bin6mA==|eeu5GgtXvmGysKMmRDWISee85yZZolGc0zBgdQ==|y/NQfIBzH01PcdK+BzBPXA=="; expires=Thu, 19-Mar-2020 01:16:17 GMT; HttpOnly; path=/
Location: http://op.com/authorization
redirect_uri=http://rp.com/code_flow/oidc_op
&scope=openid+profile+email+address+phone
&response_type=code
&nonce=cdYrYNLv6wBHlBmZjWxvrQmm
&state=DJOfvYDSDxaPzOKRoyaTaQWCoWywdeKU
&client_id=EqAfEpR492It

5、POST op.com/token：Интерфейс токена（Token Конечная точка), необходимо реализовать: （1）проверятьRPсуществовать Заголовок запросаAuthorizationполе пройденоHTTP Базовый проверяет подлинность входящих client_id и client_secret. （2）проверятьRPсуществоватьпросить体中传入изcode、grant_type、state、redirect_uri、client_idи другие параметры。Если проверка не удалась,возвращатьсяРеакции на ошибки, указанные OIDC。 (3) Если все проверки пройдены, доступ создается. token、id токен и возврат.

HTTP/1.1 200 OK
Content-Type: application/json

{ 
   
	"state": "DJOfvYDSDxaPzOKRoyaTaQWCoWywdeKU", 
	"scope": "openid profile email address phone", 
	"access_token":"Z0FBQUFBQmVjdWxLcFBWVnFzMmJ3ckcxa1ptM21kS1lDd01rY0hsVUk1WFlkUTk2MXlrN3BkdmpjTGx0VGxFeXg0SlNfVWExNldqeExRZ0RhdWt6b1Ewdy12aWlueTRMc29sc01WOHg1QXhxWjFiU1BBMmhGX2FQZnZhSUJmQVJ4eUphZ0xWRjk3M3M5MUZ0eTlVZEJxOXFtSGNuZlNaS3BqU0ZKSFBoZXE1dWdjOE13alZhLTh3Z1NVQ191V3p5a2tCSjRsT01fYVVFTV9DQmc5UFFVZnBiUmVHSXJvdzdVYzctMzJwaHVoWkFDem5MUmo4YnB2WT0=", 
	"token_type": "Bearer", 
	"id_token":"eyJhbGciOiJSUzI1NiIsImtpZCI6InZPQnl2cjBRbTBfVUI4RFZwMkRjRVNUeWt0OHZ5bV9PS1F2VjBhRm1yQWMifQ.eyJpc3MiOiAiaHR0cDovLzEyNy4wLjAuMTo4MDAyIiwgInN1YiI6ICIwMTFkYmUwMWFhYjZkZDQ1MWJlNDIzYmI0ZDI0MWFlOWM0OTA0YzJjN2FkOTk0Yzk4YmRhOGRkNmI3Y2VhYWYwIiwgImF1ZCI6IFsicTg5TFBjNkkwQTRqIl0sICJleHAiOiAxNTg0Njc1NTMwLCAiYWNyIjogInBhc3N3b3JkIiwgImlhdCI6IDE1ODQ1ODkxMzAsICJzaWQiOiAiZGNiN2E0ODlmM2JkNWY1Y2E0YmViZGFhYWY3ZjczMzY4ZjJkZTRhMDQ4YzYwNGUyMjBmOTRhNTQiLCAibm9uY2UiOiAiVzR6NldpUzF1djlwME1jMnJaNWc1Yng3In0.Jfvl4aCJy54YRbWobj7ozQUkfA2XezHtDwZhu7t5cNaguUuxNJ-epGTaub3DfmGcXI__CB_BXuQ-phWXqbz7YQ0jbwk6HtO6pGJCHfxGmcEHisM0z_-6BwJVrm6JbVw90m4zdmen5F_palkHyI4giYtrbNA8bIAraG-pZ5jZRJOmTIWHNGKopIHhUuzv39H1Ydgn5WROgz9lk24vHmyqiXiyCl2GXFcso6tEHtU9rM5oaGbIrZb6M0HfbxgmoagAw9Z9yG3p6DDihsiHUjWVccZ8o_IwS6NfJb16WFE2NoGlUBvv3Vt7VFoJJlNtTSjc7CMCij1p8k_FiN7nPMoq8w"
	}

6、GET op.com/userinfo：Интерфейс сведений о пользователе（UserInfo Конечная точка), необходимо реализовать: （1）проверятьRPсуществовать Заголовок запросаAuthorizationпройти в полеBearer关键字传入изaccess token。Если проверка не удалась,возвращатьсяРеакции на ошибки, указанные OIDC。 (2) Если проверка пройдена, верните данные пользователя.

2.2 Единый выход из системы

OIDC通过расширенный протоколпоставлять了两种Механизм выхода из системы：Front-Channel Logout и Back-Channel Logout . Если OP поддерживает оба механизма выхода из системы, RP может выбрать любой из них при регистрации.

2.2.1 Процесс

1. Когда пользователь нажимает кнопку выхода из системы,触отправить запросGET rp.com/logout,RP очищает статус сеанса пользователя,重定КприезжатьOPиз Единый выходинтерфейс（End Session Конечная точка). Эта RP называется активной RP выхода из системы. 2、OPиз Единый выходинтерфейсGET op.com/end_sessionОтвечает за создание JWT, содержащего uid, sid, client_id, redirect_uri и другую информацию.,Снова重定КприезжатьOPиз登出验证интерфейс。 3、OPиз登出验证интерфейсGET op.com/logout_verifyанализироватьJWT,Найдите всю информацию о RP, в которую вошел пользователь, на основе sid и client_id.,Уведомите этих RP по одному о необходимости пассивного выхода из системы.,В то же время очистите статус сеанса пользователя в OP. Наконец, перенаправление на post_logout_redirect_uri, предоставленное активным RP выхода из системы.,Сообщите ему, что пользователь успешно вышел из системы。 4. При активном выходе из системы RP получает запрос на post_logout_redirect_uri и возвращает пользователю страницу успешного выхода из системы. 6. Когда RP пассивного выхода из системы получает запрос на frontchannel_logout_uri или backchannel_logout_uri, он очищает состояние сеанса пользователя. 7. Когда пользователь обновляет страницу входа в систему пассивного RP, на странице отображается сообщение о том, что пользователь вышел из системы.

2.2.2 RP необходимо предоставить при регистрации в OP

1. post_logout_redirect_uri: обязательный интерфейс для получения уведомления об успешном выходе ОП при активном выходе из системы. 2. Выберите один из двух механизмов отмены:

• Если принят механизм выхода из переднего канала, дополнительно укажите: (1) frontchannel_logout_uri: обязательный интерфейс для получения уведомления о выходе OP при пассивном выходе из системы. (2) frontchannel_logout_session_required: необязательно, значение True означает, что OP должен предоставить параметры iss и sid при обратном вызове frontchannel_logout_uri, в противном случае оно не будет передано.
• Если принят механизм выхода из обратного канала, дополнительно укажите: (1) backchannel_logout_uri: обязательный интерфейс для получения уведомления о выходе OP при пассивном выходе из системы. (2) backchannel_logout_session_required: необязательно, значение True означает, что OP должен предоставить параметры iss и sid при обратном вызове Channel_logout_uri, в противном случае оно не будет передано.

2.2.3 Интерфейсы, связанные с RP

1、GET rp.com/logout：Когда пользователь нажимает кнопку выхода из системы,Запустить этот интерфейс,необходимо осознать: (1) Очистите состояние сеанса пользователя (установите пустое значение файла cookie, указанного RP). (2) ВоляOPиз Обязательные параметры уникального интерфейса вывода Разделить на продуктыполный URI,Перенаправление через браузер,Что возвращает:

HTTP/1.1 303 See Other
Location: http://op.com/end_session?id_token_hint=eyJhbGciOiJSUzI1NiIsImtpZCI6InZPQnl2cjBRbTBfVUI4RFZwMkRjRVNUeWt0OHZ5bV9PS1F2VjBhRm1yQWMifQ.eyJpc3MiOiAiaHR0cDovLzEyNy4wLjAuMTo4MDAyIiwgInN1YiI6ICIwMTFkYmUwMWFhYjZkZDQ1MWJlNDIzYmI0ZDI0MWFlOWM0OTA0YzJjN2FkOTk0Yzk4YmRhOGRkNmI3Y2VhYWYwIiwgImF1ZCI6IFsibWg2OVdDanR0YTVYIl0sICJleHAiOiAxNTg0NjkzMjgzLCAiYWNyIjogInBhc3N3b3JkIiwgImlhdCI6IDE1ODQ2MDY4ODMsICJzaWQiOiAiOWYxZTRhMjIwZDIwOGQwYWUzMTFmYzUxMzNlNTlhYzFmNDAyNjM0ZTA2ZDE2YjVmZTIwZmI2OTIiLCAibm9uY2UiOiAiSmEweXZESjFuQ1VjQjNwQk1xOXZvN09KIn0.HL56KJiE11oEZNWFai3BJczcmXHoPzizlfOTSl2q0cpUjKE9Y-Ku6O968Fbcm_fwLVTHkJBiSmmqv9DIGFa10SUuTl6Yc7rWUKgwUsIKavQ16OMBwX2XQ2TGGEq5DAodSpbdJegPfX9Q5mjk4-NfCW2aLC9fNJN-6wQtq8wZSDyc4pHUtkufioA5f114RMgMHtmg2_ws-gN1PN_twKsidzi8BFKHg2QRHUV_8-WxzS4nQPTvWIH4YdmesexZ8_VgmGQx6NtTqiVlNq_ojz50r1KaQ3lJ8PBG9X1iMxElRrjEE1ZH-4lQ9db_lDmVbCn-hYvt1QtbbYa9Oi641J0dHg
&post_logout_redirect_uri=http%3A%2F%2F127.0.0.1%3A8001%2Flogout_success%2Foidc_op

Параметры передачи:

• post_logout_redirect_uri: требуется. Когда пользователь успешно выйдет из OP, OP перезвонит этому интерфейсу, чтобы уведомить RP об активном выходе. Он должен соответствовать post_logout_redirect_uri, указанному при регистрации.
• id_token_hint: обязательно, RP будет Единый Идентификатор, полученный при входе Токен предоставляется OP как id_token_hint, чтобы сообщить OP, какой пользователь хочет выйти из системы. （这两个参数是существоватьOIDCрасширенный протоколSession Management中规定из）

2、GET rp.com/logout_success：Прямо сейчасRPпоставлятьизpost_logout_redirect_uri, Когда OP перезвонит, верните пользователю страницу успешного выхода. 3、GET rp.com/frontchannel_logout_callback：братьfrontchannelМеханизм выхода из системы,Интерфейс для получения уведомления о выходе OP, когда RP пассивно выходит из системы.,Необходимо добиться: (1) Если OP предоставляет параметры iss и sid при обратном вызове этого интерфейса,Затем проверьте. Если проверка не удалась,возвращатьсяРеакции на ошибки, указанные OIDC。 (2) Очистите состояние сеанса пользователя (установите пустое значение файла cookie, указанное RP). 4、POST rp.com/backchannel_logout_callback：братьbackchannelМеханизм выхода из системы,Интерфейс для получения уведомления о выходе OP, когда RP пассивно выходит из системы.,необходимо осознать： (1) Получите параметр logout_token, переданный OP через тело запроса, и используйте ключ подписи и другую информацию, предоставленную OP, для проверки logout_Подлинности. токена. (2) Если logout_token содержит iss、sid,Затем проверьте. Если проверка не удалась,возвращатьсяРеакции на ошибки, указанные OIDC。 (3) Очистите состояние сеанса пользователя (установите пустое значение файла cookie, указанное RP).

2.2.4 Интерфейсы, связанные с ОП

1、GET op.com/end_session：Единый Выходной интерфейс отвечает за создание JWT, содержащего uid, sid, client_id, redirect_uri и другую информацию, а также перенаправление на интерфейс проверки выхода из системы OP. 2、GET op.com/logout_verify：登出验证интерфейс,необходимо осознать： (1) Получите и проанализируйте JWT, найдите всю информацию RP, в которую вошел пользователь, на основе sid и client_id, и уведомите эти RP о пассивном выходе из системы один за другим.

• Если RP предоставляет frontchannel_logout_uri при регистрации, создайте html с помощью iframe и src=frontchannel_logout_uri iframe (то есть OP просит браузер уведомить все RP, которые используют механизм выхода из переднего канала, о пассивном выходе из системы).
• Если RP предоставляет backchannel_logout_uri при регистрации, то отправьте запрос POST на backchannel_logout_uri в фоновом режиме, передав logout_token (то есть сам OP уведомляет все RP, которые используют механизм выхода из обратного канала, о пассивном выходе из системы).

(2) Очистите состояние сеанса этого пользователя (OP устанавливает пустое значение файла cookie с именем pyoidc). (3) Независимо от того, использует ли RP механизм выхода из системы по переднему или обратному каналу, конечным возвратом этого интерфейса является HTML-код, содержащий файл сценария js. После загрузки страницы он переходит к post_logout_redirect_uri, предоставленному RP, для активной работы. выйти из системы.

2.3 Непрерывный мониторинг

Сеанс расширенного протокола OIDC ManagementоговоренныйRPкак Непрерывный мониторинг用户существоватьOPАвторизоваться状态из方法。此расширенный протокол既可以与两种Механизм выхода из системы分开使用,Также может использоваться в сочетании с。Специально для чистых JS-приложений без серверной части.,Ни один механизм выхода из системы не может быть использован.,Затем вы можете использовать метод, предусмотренный этим протоколом расширения. Непрерывный мониторинг пользовательской динамики.,Реализуйте пассивный выход из системы.

2.3.1 Процесс

1、OP из Интерфейс авторизацииGET op.com/authorizationсуществовать重定Кприезжатьredirect_uri（GET rp.com/code_flow）并возвращаться Авторизовать码и другая информация ДаватьRPиз同时（Прямо сейчас Единый входпроцессшаг3）,Дополнительный параметр session_state предоставляется RP.,Представляет статус входа пользователя в OP.,OP также устанавливает файл cookie с именем pyoic_session для предоставления информации для последующего использования op_iframe.

2、RPизredirect_uri（GET rp.com/code_flow）Воля收приезжатьизsession_stateсохрани это,Затем создайте HTML для возврата в качестве ответа.,HTML中包含两个用于监视会话状态изiframe：rp_iframe（GET rp.com/session_iframe）иop_iframe（GET op.com/check_session_iframe）,HTML также содержит файл сценария js.,После загрузки страницы,Перейти на последнюю страницу, просмотренную пользователем перед входом в систему.

3、op_iframe（GET op.com/check_session_iframe）,Отвечает за получение сообщений от rp_iframe через postMessage.,Затем прочитайте файл cookie pyoic_session ОП.,Извлеките необходимую информацию,Вычислите правильное значение session_state,И сравните его со значением session_state, отправленным rp_iframe. если оба одинаковы,затем вернитесь без изменений,В противном случае возврат изменится.

4. rp_iframe отвечает за его использование согласно установленному временному интервалу postMessage Отправьте указанное сообщение на опрос op_iframe, таким образом Непрерывный мониторинг用户существоватьOPиз Авторизоваться状态是否变化。Если получено от op_iframe, возвращается без изменений.,Затем продолжайте наблюдение. Если то, что получено, изменено,тогда позвониGET rp.com/session_change这个интерфейс进行处理。

5、GET rp.com/session_change负责ВоляOP Интерфейс авторизации и необходимые параметры собираются в полный URI, такой же, как и раньше (т.е. Единый входпроцессшаг1）из Передача параметров相比,Дополнительно предоставляется Promptиid_token_hint,Перенаправление через браузер До сих порURI。

6、OPиз Интерфейс авторизацииGET op.com/authorizationВоля照常响应该просить（Единый входпроцессшаг3）,Снова次重定Кприезжатьredirect_uri（GET rp.com/code_flow）,в это времяGET rp.com/code_flowВоля做： (1) Если пользователь, представленный новым полученным id_token, совпадает с пользователем, представленным исходным id_token, что указывает на то, что пользователь все еще нормально вошел в систему на OP, сохраните новое значение session_state, повторите шаги 1–4 и возобновить мониторинг. (2) Напротив, если пользователь, представленный новым id_token, отличается, или новый id_token не получен, или в других ненормальных обстоятельствах, будет считаться, что пользователь вышел из системы в OP, а статус сеанса пользователя в РП будет очищен.

2.3.2 Интерфейсы, связанные с RP

1、GET rp.com/code_flow：此интерфейссуществовать原功能（Единый вход Интерфейсы, связанные с На основе RP3) требуется дополнительная реализация: (1) Сохраните три информации session_state, client_id и эмитента отдельно для последующего использования. (2) Создайте HTML-код, который будет возвращен в качестве ответа. HTML-код содержит два скрытых iframe: rp_iframe：Ответственный за звонокGET rp.com/session_iframe这个интерфейс。 op_iframe：Ответственный за звонокGET op.com/check_session_iframe这个интерфейс。 (3) HTML также содержит файл сценария js. После загрузки страницы происходит переход к последней странице, просмотренной пользователем перед входом в систему. (4) Когда ОП снова перенаправляется на этот интерфейс (Непрерывный мониторингпроцесс6), когда передается обновленное значение id_tokenиsession_state, проверяется новый id_token. Если пользователь, представленный новым полученным id_token, совпадает с пользователем, представленным старым id_token, новое значение session_state сохраняется. Наконец, возвращается созданный HTML. (5) Напротив, если проверка не удалась, или пользователь, представленный новым id_token, отличается, или новый id_token не получен и т. д., следует считать, что пользователь вышел из OP и сеанса пользователя. статус в RP должен быть очищен (установите значение cookie, указанное RP, в пустое значение).

2、GET rp.com/session_iframe：получатьrp_iframeизинтерфейс,необходимо осознать： (1) Найдите три сохраненные данные: session_state, client_id и эмитент. (2) Создайте HTML-код для возврата в качестве ответа. Этот HTML-код — rp_iframe, который отвечает за его использование в соответствии с установленным интервалом времени. postMessage Отправьте указанное сообщение на опрос op_iframe, таким образом Непрерывный мониторинг用户существоватьOPиз Авторизоваться状态是否变化。Укажите сообщение какvar message = client_id + " " + session_state,Если получено от op_iframe, возвращается без изменений.,Затем продолжайте наблюдение. Если то, что получено, изменено,тогда позвониGET rp.com/session_change。

3、GET rp.com/session_change：когдаrp_iframeПри обнаружении изменения состояния сеанса,Вызовите этот интерфейс для обработки,Необходимо добиться: (1) Соберите интерфейс авторизации ОП и необходимые параметры в полный URI.,Перенаправление через браузер,Что возвращает:

HTTP/1.1 303 See Other
Location: http://op.com/authorization
?redirect_uri=http://rp.com/code_flow/oidc_op
&scope=openid+profile+email+address+phone
&response_type=code
&nonce=cdYrYNLv6wBHlBmZjWxvrQmmD
&state=DJOfvYDSDxaPzOKRoyaTaQWCoWywdeKU
&client_id=EqAfEpR492It
&prompt=none
&id_token_hint=eyJhbGciOiJSUzI1NiIsImtpZCI6InZPQnl2cjBRbTBfVUI4RFZwMkRjRVNUeWt0OHZ5bV9PS1F2VjBhRm1yQWMifQ.eyJpc3MiOiAiaHR0cDovLzEyNy4wLjAuMTo4MDAyIiwgInN1YiI6ICIwMTFkYmUwMWFhYjZkZDQ1MWJlNDIzYmI0ZDI0MWFlOWM0OTA0YzJjN2FkOTk0Yzk4YmRhOGRkNmI3Y2VhYWYwIiwgImF1ZCI6IFsiNVRsMFhFbWNhZnBlIl0sICJleHAiOiAxNTg0NzE2MjkzLCAiYWNyIjogInBhc3N3b3JkIiwgImlhdCI6IDE1ODQ2Mjk4OTMsICJzaWQiOiAiYjg5NGRkZmZmMDgyOGY0YjRkMzg3NzE2MzcyY2ViZGVhZjg1ZjNkZWM3Nzk2OGExYjc2MTg1NjMiLCAibm9uY2UiOiAiSkhRS0w3Um0wZ2FCSW9oakpPRHZVcEZaIn0.Ma14vJMfTUBmQlG0vduKoUAjzMnhrQEn6FYTP5QQbAC4imJZWovqlgyijJpVbf9B3oevX4zc_i-19Stb7CdHVy9k_zuTYN7RRgo60Oz7k4WnAU-4NdmcmHD1MSHJUJpSLZcTPL81kc_YNGHHvxgOW217OOfF1yqfQADyvbwI4GNq05rq4R3mlkt3wdZGQaewJKC1qSMckaEAgtWbE4Iaj71uIoHuG_KHJdoY2CxSvbzBV55AN8soOL7kiPWfn6uIuDJVIFGTlL9ufRKogh7gDbKbUQ91q5yY1ARfP70z8LCnFI1ceLqJuJALa5FItRnayfO_RI2txVoGrWDyOd1F_g

Предусмотрены дополнительные 2 параметра передачи:

• prompt=none,При получении данного запроса от имени ОП нет необходимости уведомлять пользователя через страницу авторизации.,Этот запрос используется только для получения обновленного значения id_token и значения session_state.
• id_token_hint=RPЕдиный Значение id_token, полученное, когда вход используется, чтобы сообщить OP, новое значение id_token и значение session_state какого пользователя он хочет получить.

2.3.3 Интерфейсы, связанные с ОП

1、GET op.com/authorization：Интерфейс авторизациисуществовать原功能（Единый вход Интерфейсы, связанные с На основании ОП3) требуется дополнительная реализация: (1) Дополнительный параметр session_state предоставляется RP, который представляет статус входа пользователя в OP. Он непрозрачен для RP. (2) Установите файл cookie с именем pyoic_session, чтобы предоставить информацию для последующего использования op_iframe.

2、GET op.com/check_session_iframe：получатьop_iframeизинтерфейс,Необходимо добиться: Вернуть HTML непосредственно в качестве ответа,Этот HTML-код — op_iframe,Отвечает за получение сообщений от rp_iframe через postMessage.（client_id + " " + session_state）,Затем прочитайте собственный файл cookie pyoic_session ОП.,Извлеките необходимую информацию,Вычислите правильное значение session_state,И сравните его со значением session_state, отправленным rp_iframe. если оба одинаковы,затем вернитесь без изменений,В противном случае возврат изменится.

3. Интегрируйте сторонний вход (GitHub) в единый вход OIDC.

Приведенный выше пример находится в Едином для входа используется пароль учетной записи собственной системы. Одно из преимуществ OIDC совместимо с многочисленными IDP (поставщиками удостоверений) и легко интегрируется. Вход третьего Лицо, RP SSO требует лишь очень незначительных изменений. В этом примере используется GitHub OAuth 2.0 как IDP, но типы IDP, поддерживаемые OIDC, не ограничиваются OAuth. 2.0, он также поддерживает SAML, WS-Federation, Windows. AD или часто используемый код подтверждения SMS для мобильного телефона и т. д. Это связано с тем, что OIDC не заботится о том, как OP завершает аутентификацию пользователя ([Q1]), его заботит только то, как безопасно и надежно передавать идентификационную информацию пользователя от OP к RP ([Q2]).

Механизм аутентификации, задействованный в этом примере: (1) В качестве идентификационного пользователя rp.com использует механизм аутентификации OIDC, такой же, как в приведенном выше примере. (2) В качестве сервера авторизации op.com должен подтвердить личность клиентского приложения (rp.com). В этом примере используется механизм базовой аутентификации, такой же, как в приведенном выше примере. (3) В качестве идентификационного пользователя (посредника) op.com использует механизм аутентификации OIDC. (3) GitHub как поставщик удостоверений должен проверять удостоверения пользователей, используя механизм аутентификации с помощью формы. (4) В качестве сервера авторизации GitHub должен проверять личность клиентского приложения (op.com). GitHub поддерживает как базовые параметры, так и параметры тела запроса POST, и клиентское приложение (op.com) может выбрать любой из них.

3.1 Процесс

1. Когда RP требует от пользователя входа в систему, позвольте пользователю выбрать метод входа в систему. Пользователь выбирает вход в систему с помощью Github (то есть передавая параметр iss=github), который срабатывает при отправке формы. GET rp.com/login?iss=github,это будетOPиз Интерфейс авторизациии Обязательные параметры（RPизredirect_uri：GET http://rp.com/code_flow/oidc_op）组装成完整изURI（В данном случае это называетсяauthz_uri）,Перенаправление через браузер。

2、OPИнтерфейс авторизацииGET op.com/authorization发现用户未существоватьOPАвторизоваться（не носит имяpyoidcизcookie）,Таким образом, пользователь аутентифицируется через Github.,Прямо сейчас ВоляGithubИнтерфейс авторизацииGET https://github.com/login/oauth/authorizeи Обязательные параметры（OPизredirect_uri：GET op.com/github/verify）组装成完整изURI,Перенаправление через браузер,Github аутентифицирует пользователей. После того, как пользователь войдет в Github и авторизуется,GithubСнова Перенаправление через браузерприезжатьOPизredirect_uri,При этом указывается код (код авторизации) и состояние.

3、OPизredirect_uri（GET op.com/github/verify）使用收приезжатьиз Авторизовать码КGithubИнтерфейс токенапроситьaccess токен, использовать доступ Токен запрашивает данные пользователя из интерфейса данных пользователя Github и привязывает их к своей собственной системе учетных записей. На этом этапе аутентификация пользователя проходит. OP устанавливает состояние сеанса пользователя (устанавливает файл cookie с именем pyoidc) и перенаправляет на authz_uri.

4. Браузер поддерживает перенаправление файлов cookie.,Введите еще разOPИнтерфейс авторизацииGET op.com/authorization,Обнаружено, что пользователь вошел в систему на OP (файл cookie с именем pyoidc прошел проверку),Итак, выполните логику авторизации,Выдать код авторизации ОП,Перенаправление на redirect_uri RP (предоставленное RP на шаге 1).

5. redirect_uri RP получает код авторизации OP и использует код авторизации для запроса доступа из интерфейса токена OP. идентификатор токена токен, использовать доступ Токен запрашивает данные пользователя из интерфейса сведений о пользователе OP.

3.2 Интерфейсы, связанные с RP

1、GET rp.com/login?iss=github：Передача параметровiss=githubУказывает, что пользователь решил использоватьGithubВход третьего лица,Этот интерфейс отвечает за сборку интерфейса авторизации OP и необходимых параметров в полный URI.,Перенаправление через браузер,Что возвращает:

HTTP/1.1 303 See Other
Location: http://op.com/authorization
?redirect_uri=http://rp.com/code_flow/oidc_op
&scope=openid+profile+email+address+phone
&response_type=code
&nonce=qku5JVdjlKjnbsF5hpRBJwdz
&state=c7HBU6Sb1nAcWELJx6l2aUsQfnwIl0EW
&client_id=EqAfEpR492It
&acr_values=github

дополнительный Параметры передачи:

• acr_values: указывает, что OP должен использовать github в качестве IDP (поставщика аутентификации личности).

Видно, что изменения в RP очень малы. Для реализации входа в Github необходим только один параметр (acr_values=github). Если OP также поддерживает вход в WeChat, то RP необходимо передать только acr_values=wechat.

3.3 Интерфейсы, связанные с ОП

Сохраните информацию о конфигурации IDP (Github): (1) Интерфейс авторизации (Авторизация Endpoint）：GET https://github.com/login/oauth/authorize (2) Интерфейс токена (токен EndPoint）：POST https://github.com/login/oauth/access_token (3) Интерфейс сведений о пользователе (UserInfo EndPoint）：GET https://api.github.com/user （4）client_id、client_secret：需手动КGithub注册получать：https://github.com/settings/applications/new （5）scope：确定需要КGithubНа какие разрешения на ресурсы подавать заявку?。Дополнительная область действия, предоставляемая Github.

1、GET op.com/authorization：Интерфейс авторизациисуществовать原功能（Единый вход Интерфейсы, связанные с На основании ОП3) требуется дополнительная реализация: （1）找出Передача параметровacr_values指定изIDP（Github）из配置信息,Соберите интерфейс авторизации Github и необходимые параметры в полный URI.,Перенаправление через браузер,Что возвращает:

HTTP/1.1 303 See Other
Location: https://github.com/login/oauth/authorize
?redirect_uri=http://op.com/github/verify
&scope=public_repo+user
&state=c7HBU6Sb1nAcWELJx6l2aUsQfnwIl0EW
&client_id=9c21477eb0a5e2191342

Параметры передачи:

• redirect_uri：OPизredirect_uri：GET op.com/github/verify
• client_id: client_id, зарегистрированный ОП на Github.
• область действия: выбирается из значений области действия, предоставленных Github
• состояние: для удобства состояние параметра соответствует состоянию, предоставляемому RP.
• Поскольку Github поддерживает только процесс кода авторизации (тип предоставления кода авторизации) для веб-приложений, поэтому он не задает тип_ответа.

Передача параметров, поддерживаемых интерфейсом авторизации Github：

4、GET op.com/github/verify：Прямо сейчасOPизredirect_uri,此интерфейснеобходимо осознать： (1) Получите код (код авторизации) и состояние, возвращенные GitHub, и проверьте значение состояния. （2）使用Авторизовать码существовать后台КGitHubиз Интерфейс токенаPOST https://github.com/login/oauth/access_tokenпроситьaccess_token。

Передача параметров, поддерживаемых интерфейсом токена Github：

Уведомление:

• client_id и client_secret можно передать через тело запроса POST или через базовую аутентификацию HTTP заголовка запроса. Интерфейс токена GitHub поддерживает оба метода.
• GitHub не использует стандартный протокол OIDC. Его интерфейс токенов будет возвращать только токены доступа, а не токены идентификатора.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{ 
   "access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a", "scope":"public_repo,user", "token_type":"bearer"}

(3) Использовать доступ_tokenсуществовать后台КGitHubиз Интерфейс сведений о пользователеGET https://api.github.com/userпросить用户详细信息。通过Заголовок запросаAuthorizationизBearerПередача ключевых словaccess token。 (4) Свяжите данные пользователя с вашей собственной системой учетных записей.

Справочная документация

1. [Сертификация & Авторизация] 4. OIDC（OpenId Connect) аутентификация личности (основная часть)
2. [Сертификация & Авторизация] 5. OIDC（OpenId Connect) Аутентификация личности (расширенная часть)
3. Начало работы с протоколом OpenID Connect
4. Официально сертифицированная библиотека реализации OIDC (C, C#, Java, JavaScript, Python, PHP, Ruby и т. д.)
5. [OIDC в ​​действии] 1. Единый вход на основе OIDC (OpenID Connect)
6. [OIDC в ​​действии] 2. SSO (чистый JS-клиент) на основе OIDC (OpenID Connect)
7. [OIDC в ​​действии] 3. Единый вход на основе OIDC (OpenID Connect) (добавлена ​​поддержка Github OAuth 2.0)
8. Пример руководства по GitHub OAuth Вход в третье лицо
9. Краткое обсуждение SAML, OAuth, OpenIDиSSO, JWTиSession
10. Аутентификация и авторизация — инвентаризация протоколов единого входа: OpenID, OAuth2 и SAML
11. Учебное пособие по началу работы с веб-токеном JSON
12. Руководство по началу работы с OpenID Connect Federation
13. WebВ приложении Идентификация на основе пароля. Механизм аутентификации. (аутентификация по форме, HTTP-аутентификация: Basic、Digest、Mutual）
14. OAuth 2.0 Лицензионное соглашение (на предъявителя token）

Издатель: Full stack программист и руководитель стека, укажите источник для перепечатки: https://javaforall.cn/179103.html Исходная ссылка: https://javaforall.cn