Это правильное использование OpenID Connect для данного варианта использования?

Я пытаюсь понять, как использовать OpenId Connect в следующем примере использования. Допустим, у нас есть только следующие 3 компонента:

  • Веб-приложение с открытым API (поставщик услуг, также известный как SP).
  • Отдельный сервер аутентификации (Identify Provider aka IDP), используемый для SSO с указанным выше SP.
  • Собственное клиентское приложение, используемое Конечным пользователем. Это клиентское приложение использует API SP.

Весь трафик будет через HTTPS. Вот как я представляю работу процесса OpenID Connect:

  1. Собственное приложение запросит «токен» у SP.
  2. SP увидит, что пользователь не аутентифицирован, и запросит подтверждение у доверенного IDP.
  3. После того, как учетные данные пользователя будут предоставлены IDP, IDP вернет токен ID и токен доступа SP.
  4. SP проверит токен идентификатора и предоставит токен доступа собственному клиентскому приложению для использования во всех последующих запросах к API.

Это рекомендуемый способ использования OpenID Connect в данной ситуации? Есть ли очевидные проблемы с безопасностью? Единственное, что я вижу, это то, что собственное клиентское приложение может использовать токен доступа для доступа к конечной точке информации о пользователе в IDP.


authentication openid-connect single-sign-on openid
person AndyB    schedule 18.05.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Относительно пунктов 1-4:

  1. Токены, запрошенные у IDP, а не у SP. (обычно IDP размещаются на отдельном поддомене). Мне нравится термин STS (Security Token Service), а не IDP, который легко описывает роль сервера OIDC: программного обеспечения, которое выдает токены.

  2. Я предпочитаю сказать: каждый запрос от собственного приложения к SP, который защищен (не анонимен), должен быть подтвержден STS / IDP. Считайте IDP межсетевым экраном между защищенными ресурсами / API / SP и native-app / RP / client.

  3. Ответ IDP зависит от того, какой поток используется (код, неявный, гибридный, владелец ресурса, учетные данные клиента). Эта суть может помочь быстро понять потоки: OIDC и OAuth2 Flows

  4. Идентификационный токен разработан и предназначен для использования клиентским / RP / собственным приложением.

Я думаю, что описанный вариант использования очень часто обрабатывается OpenIDConnect + OAuth2. о доступе к конечной точке информации о пользователе, это полностью зависит от конфигурации вашего IDP и конфигурации RP / Client / NativeApp.

пример: я использую IdentityServer3 в качестве IDP / STS (его официально сертифицированного поставщика OpenID Connect): в IdentityServer3 я могу отключить любую конечную точку через конфигурацию и ограничить области действия RP.

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

надеюсь, что это полезно.

person Jawad Al Shaikh    schedule 23.05.2015
comment
Чтобы расширить свой комментарий об этом варианте использования, который обрабатывается OIDC + OAuth2, это, вероятно, лучшее решение. SP не будет передавать токен доступа собственному приложению. SP будет использовать его только для доступа к конечной точке информации о пользователе на IDP. Затем SP сгенерирует собственный токен OAuth, чтобы передать его собственному приложению для последующих вызовов. В основном используйте OIDC для аутентификации пользователя и OAuth для отслеживания сеанса с помощью собственного приложения. Это обеспечило бы лучшее разделение. - person AndyB; 28.05.2015
comment
Я не уверен, что понимаю, как это обеспечивает лучшее разделение (и в чем смысл?). любой поставщик OP (OIDC) неявно является поставщиком OAuth2. OIDC не может существовать без OAuth2. Таким образом, OP должен обрабатывать всю логику аутентификации и авторизации, включая управление сеансом. как SP генерирует собственный токен OAuth? отсюда? также SP является поставщиком данных, так почему вы хотите возложить на него ответственность за безопасность помимо обслуживания данных. надеюсь, что это полезно, хотя я могу неправильно понять. - person Jawad Al Shaikh; 29.05.2015