Потоки IdentityServer

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

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

Спасибо!

Ответы

Ответ 1

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

Обогащение документации IdentityServer с помощью потока OIDC и потока OAuth2 # 73

Обновление: OIDC и OAuth2 Потоки

Ответ 2

От наименьшего приоритета первой ссылки: и Аарон Паретски OAuth 2 Упрощенный

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

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

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

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

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

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

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

Ответ 3

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

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/

Ответ 4

Потоки, определенные в 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/Password)

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

Этот поток идеален для клиентов, которым, по вашему мнению, абсолютно безопасно делиться с ними идентификаторами и паролями.

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

Это комбинация Authorization code flow и Authorization code flow Implicit code flow. Вот почему он называется Hybrid.

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

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

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