Каков правильный эмитент токена oid c id - PullRequest
Новая
       87

Каков правильный эмитент токена oid c id

0 голосов
/ 08 мая 2020

Каким должен быть эмитент для реализации микросервиса oid c, который будет обеспечивать авторизацию для нескольких клиентов, различающихся по разным доменам?

SPE c говорит:

ОБЯЗАТЕЛЬНО. Идентификатор эмитента для эмитента ответа. Значение iss представляет собой чувствительный к регистру URL-адрес с использованием схемы https, которая содержит схему, хост и, необязательно, номер порта и компоненты пути, но не компоненты запроса или фрагмента.

Он не указывает, действительно ли это идентификатор должен соответствовать домену запроса или вообще быть реальным URL-адресом. Сделав это URL-адресом c, который просто идентифицирует эту службу, упростит проверку в некоторых других микросервисах.

Превращает ли его stati c url в какое-либо нарушение SP c или есть другие подводные камни, которые могут быть не сразу очевидны?

1 Ответ

1 голос
/ 10 мая 2020

OpenID Connect Discovery 1.0 включает набор ошибок 1 состояния:

эмитент

ТРЕБУЕТСЯ. URL-адрес с использованием схемы https без компонента запроса или фрагмента, который OP утверждает в качестве своего идентификатора эмитента. Если обнаружение эмитента поддерживается (см. Раздел 2), это значение ДОЛЖНО быть идентично значению эмитента, возвращаемому WebFinger. Это также ДОЛЖНО быть идентично значению заявки iss в токенах ID, выданных этим эмитентом.

В спецификации «OpenID Connect Core 1.0, включающий набор ошибок 1» указано:

16,15. Идентификатор эмитента OpenID Connect поддерживает несколько эмитентов на комбинацию хоста и порта. Эмитент, возвращенный обнаружением, ДОЛЖЕН точно соответствовать значению iss в идентификаторе токена.

OpenID Connect рассматривает компонент пути любого URI эмитента как часть идентификатора эмитента. Например, тема «1234» с идентификатором эмитента «https://example.com» не эквивалентна теме «1234» с идентификатором эмитента «https://example.com/sales».

РЕКОМЕНДУЕТСЯ использовать только одного эмитента для каждого хоста. Однако, если хост поддерживает несколько клиентов, для этого хоста может потребоваться несколько эмитентов.

Нет причин ожидать, что клиент (который делает запрос авторизации) и сервер авторизации будут в одном и том же Домен DNS. Или ожидать, что клиент будет находиться в том же домене NDS, что и сервер ресурсов.

Спецификации не определяют эти отношения, поэтому любые отношения должны быть выполнены с использованием других спецификаций Inte rnet. Единственное, о чем я знаю, - это "доверительные" отношения сертификатов.

Обязательно прочтите OAuth 2.0 Security Best Current Practice

...