Потоки IdentityServer

из первой ссылки 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.