Потоки IdentityServer


IdentityServer поддерживает различные потоки OpenId Connect, которые определены в течет enum и Set для клиентов. Есть также образцы для каждого типа потока и много ссылок на них в документах, но я не смог найти простой список определений того, какие потоки находятся в документация а если они слишком очевидны, чтобы объяснить словами. Но я думаю, что это не так. Не могли бы вы рассказать больше о различиях этих, может быть, мы можем добавить, что к документы?

Так что: подразумевается поток владелец ресурса пароль поток код авторизации поток учетные данные клиента поток пользовательские грант поток, и гибрид поток? Также какие из них являются потоками OAuth, а какие-потоками OpenID Connect?

спасибо!

4   51   2015-04-16 21:55:31

4 ответа:

Я столкнулась с той же проблемой, в настоящее время работа продолжается. когда я закончу документацию, я могу опубликовать ее здесь. в настоящее время: пожалуйста, проверьте проект:

обогатите документацию IdentityServer с разделом потоков OIDC и OAuth2 #73

обновление:oidc и OAuth2 потоки

из первой ссылки leastPrivilage: и Аарон Парецки OAuth 2 упрощенный

потоки решают, как идентификатор (т. е. код авторизации) и маркер доступа (т. е. 'токен') возвращаются клиенту:

Поток Кода Авторизации: поток OAuth 2.0, в котором

  • код авторизации возвращается из Конечная Точка Авторизации
  • и все токены (как второй этап, в обмен на код авторизации) возвращается из конечной точки маркера
  • используется для вызовов на основе сервера (API), которые могут поддерживать конфиденциальность своего секретного клиента. Позволяет повысить безопасность, пока никто не может получить доступ к "секрету клиента".

Неявный Поток: поток OAuth 2.0, в котором

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

Гибридный Поток: поток OAuth 2.0, в котором

  • код авторизации возвращается из конечной точки авторизации,
  • некоторые маркеры возвращаются непосредственно из конечной точки авторизации, а другие возвращаются (как второй этап, в обмен на код авторизации) из конечной точки маркера.
  • используется там, где необходимы оба потока.

смотрите спецификации - все это уже записано:

http://openid.net/specs/openid-connect-core-1_0.html и http://tools.ietf.org/html/rfc6749

кроме того, я недавно написал резюме, которое разбивает его на различные типы приложений:

http://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/

потоки, определенные в OAuth2 есть только несколько способов для клиента, чтобы получить access token с сервера поставщика удостоверений;IdentityServer в этом случае. Понимание потоков не будет легким, если вы полностью не понимаете сущности, указанные в блок-схемы например Resource Owner,User Agent и Resource Server. Есть некоторые краткие объяснения по этим сущностям (ролям, драгоценно ) в здесь.


авторизация поток кода : вопросы authorization code до вынесения access token.

  • запрос клиента authorization code.
  • IdentityServer проверяет клиента и просит владельца ресурса предоставить разрешение на выдачу authorization code.
  • затем клиент запрашивает access token с authorization code
  • сервер авторизации выдает access token непосредственно клиент.

неявный поток код : вопросы access token даже без authorization code предусмотрено.

  • запрос клиента access token напрямую.
  • IdentityServer пропускает проверку клиента ( в некоторых сценариях она частично выполняется ), но все же просит владельца ресурса предоставить разрешение на выдачу access token
  • этот поток никогда не выдает authorization code.

неявный поток считается идеальным потоком для клиента, использующего скриптовые языки, такие как javascript так как клиент не должен запрашивать authorization code и access token отдельно, в свою очередь, уменьшая одну сеть туда и обратно для клиента.


поток учетных данных клиента : вопросы access token без разрешения владельца ресурса.

  • клиент запрашивает маркер доступа непосредственно.
  • IdentityServer проверяет клиента и выдает access token сразу.

это идеально, когда клиент также является владельцем ресурса, поэтому ему не нужны никакие разрешения на авторизацию вплоть до access token.


поток владельца ресурса : вопросы access token Если клиент имеет учетные данные владельца ресурса ( например. Id / Пароль)

  • клиент запрашивает access token напрямую.
  • IdentityServer проверяет клиента и личность владельца ресурса.
  • если действительно, клиент получает access token мгновенно.

этот поток идеально подходит для клиентов, которые вы считаете это абсолютно безопасно делиться идентификаторами и паролями с ними.


гибридный поток (поток OIDC) : вопросы authorization code и access token.

это a сочетание Authorization code flow и Implicit code flow. Вот почему он называется Hybrid.


пользовательский поток

это буквально настраиваемый поток. Это можно использовать, когда вам нужен определенный процесс аутентификации / проверки в вашем бизнесе рядом со всеми спецификациями протокола в OAuth2.

IdentityServer хорошо осведомлен о такой ситуации, и он поддерживает расширяемость по дизайну. Заводская модель, шаблон декоратора и IoC / DI облегчат вам реализацию дополнительных функций на вашем IdentityServer.