blocks|key|2918627|text|请看规范--这些都已经写下来了：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2918628|http://openid.net/specs/openid-connect-core-1_0.html和https://www.rfc-editor.org/rfc/rfc6749|offset|length|2918629|此外，我最近写了一篇总结，将其细分为不同的应用程序类型：|2918630|http://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/|2918631|entityMap|0|LINK|mutability|MUTABLE|url|http://openid.net/specs/openid-connect-core-1_0.html|1|https://www.rfc-editor.org/rfc/rfc6749|2^0|0|0|1G|0|1H|12|1|0|0|0|2H|2|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@$D|W|E|X|1|Y]|$D|Z|E|10|1|11]]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|J|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|I]]]]

see the specifications - it has been all written down already:
<a href="http://openid.net/specs/openid-connect-core-1_0.html" rel="nofollow noreferrer">http://openid.net/specs/openid-connect-core-1_0.html</a>
and
<a href="https://www.rfc-editor.org/rfc/rfc6749" rel="nofollow noreferrer">https://www.rfc-editor.org/rfc/rfc6749</a>
in addition i've recently written a summary that breaks it down for different application types:
<a href="http://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/" rel="nofollow noreferrer">http://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/</a>

blocks|key|2918657|text|我也面临着同样的问题，目前的工作还在进行中。当我完成文档后，我可能会在这里发布它。暂时:请查看草案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2918658|Enrich+IdentityServer+Documentation+with+OIDC+and+OAuth2+Flows+section+#73|offset|length|2918659|更新：+OIDC+and+OAuth2+Flows|style|BOLD|2918660|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/IdentityServer/Documentation/issues/73|1|https://gist.github.com/jawadatgithub/638c11f08ecc0d76b05c^0|0|0|22|0|0|0|3|4|L|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@$D|Z|E|10|H|I]]|9|@$D|11|E|12|1|13]]|A|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

I faced the same Issue, currently the work still in progress. when I finish the documentation, I might post it here. for time being: please check the draft:

<a href="https://github.com/IdentityServer/Documentation/issues/73">Enrich IdentityServer Documentation with OIDC and OAuth2 Flows section #73</a>

Update: <a href="https://gist.github.com/jawadatgithub/638c11f08ecc0d76b05c">OIDC and OAuth2 Flows</a>

blocks|key|2918689|text|来自至少特权的第一个链接:和Aharon+Paretzki's+OAuth+2+Simplified|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2918690|流程决定如何将ID令牌(即授权码)和访问令牌(即‘令牌’)返回给客户端：|style|BOLD|2918691|授权代码流：OAuth+2.0流，其中|2918692|2918693|从授权端点|unordered-list-item|2918694|返回授权码，并且从用于基于服务器的调用(API)的令牌端点|2918695|返回所有令牌(作为第二阶段，以换取授权码)，这些API可以维护其客户端机密。允许更强的安全性，只要没有人可以访问“客户端机密”。|2918696|2918697|隐式流：OAuth+2.0流，其中|2918698|2918699|所有令牌直接从授权终结点|2918700|返回，不使用令牌终结点或授权码。|2918701|用于移动和基于web的应用程序，无法维护客户端秘密的机密性，因此需要由身份验证服务器本身颁发令牌。这不太安全，建议将服务器设置为拒绝API使用的隐式流调用，并仅允许基于浏览器和基于移动的应用程序使用。|2918702|2918703|混合流：OAuth+2.0+flow，其中|2918704|2918705|从授权端点返回授权码，|2918706|某些令牌直接从授权端点返回，其他令牌(作为第二阶段，用于交换授权码)从需要这两个流的Token+Endpoint.|2918707|Used返回。|2918708|2918709|entityMap|0|LINK|mutability|MUTABLE|url|https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified^0|E|10|0|0|7|4|I|4|0|0|5|0|0|0|0|0|0|0|3|0|0|0|0|0|0|0|3|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|D|3|E|5|6|7|1O|8|@$A|1P|B|1Q|F|G]|$A|1R|B|1S|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|1T|8|@$A|1U|B|1V|F|G]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1W|8|@]|9|@]|C|$]]|$1|K|3|L|5|M|7|1X|8|@]|9|@]|C|$]]|$1|N|3|O|5|M|7|1Y|8|@]|9|@]|C|$]]|$1|P|3|Q|5|M|7|1Z|8|@]|9|@]|C|$]]|$1|R|3|-4|5|6|7|20|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|21|8|@$A|22|B|23|F|G]]|9|@]|C|$]]|$1|U|3|-4|5|6|7|24|8|@]|9|@]|C|$]]|$1|V|3|W|5|M|7|25|8|@]|9|@]|C|$]]|$1|X|3|Y|5|M|7|26|8|@]|9|@]|C|$]]|$1|Z|3|10|5|M|7|27|8|@]|9|@]|C|$]]|$1|11|3|-4|5|6|7|28|8|@]|9|@]|C|$]]|$1|12|3|13|5|6|7|29|8|@$A|2A|B|2B|F|G]]|9|@]|C|$]]|$1|14|3|-4|5|6|7|2C|8|@]|9|@]|C|$]]|$1|15|3|16|5|M|7|2D|8|@]|9|@]|C|$]]|$1|17|3|18|5|M|7|2E|8|@]|9|@]|C|$]]|$1|19|3|1A|5|M|7|2F|8|@]|9|@]|C|$]]|$1|1B|3|-4|5|6|7|2G|8|@]|9|@]|C|$]]|$1|1C|3|-4|5|6|7|2H|8|@]|9|@]|C|$]]]|1D|$1E|$5|1F|1G|1H|C|$1I|1J]]]]

From leastPrivilage's first link: and <a href="https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified">Aharon Paretzki's OAuth 2 Simplified</a> 

Flows decide how the ID token (i.e. the authorization code) and the Access token (i.e. 'the token') are returned to the client: 

Authorization Code Flow: OAuth 2.0 flow in which 

<ul>
<li>an Authorization Code is returned from the Authorization Endpoint </li>
<li>and all tokens (as a second stage, in exchange for the authorization code) are returned from the Token Endpoint </li>
<li>Used for server based calls (APIs) that can maintain the confidentiality of their client secret. Allows for stronger security, as long as no-one can access the "client secret".</li>
</ul>

Implicit Flow: OAuth 2.0 flow in which 

<ul>
<li>all tokens are returned directly from the Authorization Endpoint </li>
<li>and neither the Token Endpoint nor an Authorization Code are used.</li>
<li>Used for mobile and web based apps, that cannot maintain the confidentiality of the client secret, so there is a need to have the token issued by the auth server itself. This is less secure, and it is recommended that the server should be set to deny implicit flow calls for API usage, and allow it only for the browser based and mobile based apps. </li>
</ul>

Hybrid Flow: OAuth 2.0 flow in which 

<ul>
<li>an Authorization Code is returned from the Authorization Endpoint, </li>
<li>some tokens are returned directly from the Authorization Endpoint, and others are returned (as a second stage, in exchange for the authorization code) from the Token Endpoint.</li>
<li>Used where both flows are needed. </li>
</ul>

blocks|key|2918746|text|OAuth2中定义的流只是客户端从身份提供者服务器(在本例中为IdentityServer+)接收access+token的几种方式。除非您完全理解the+flow+diagrams中指定的实体，如Resource+Owner、User+Agent和Resource+Server，否则理解流程并不容易。在here中有一些关于这些实体(角色)的简要解释。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2918747|2918748|授权代码流：在发出authorization+code之前发出access+token。|BOLD|2918749|authorization+code.|2918750|IdentityServer+|unordered-list-item|2918751|
|2918752|客户端请求authorization+code.|2918753|2918754|IdentityServer，验证客户端并要求资源所有者授予颁发authorization+code.|2918755|2918756|The的授权，然后使用给定的authorization+code|2918757|2918758|The请求access+token授权服务器直接向客户端发出access+token。|2918759|2918760|2918761|隐式代码流：即使没有提供access+token，也会发出authorization+code。|2918762|流客户端请求流directly.|2918763|IdentityServer跳过验证客户端(在某些情况下，它会部分验证)，但仍会要求资源所有者授予发出access+token|2918764|This+access+token的授权从不发出authorization+code.|2918765|2918766|隐式流被认为是使用javascript等脚本语言的客户端的理想流程，因为客户端不必分别请求authorization+code和access+token，从而减少了客户端的一次网络往返。|2918767|2918768|Client+credentials+flow：在没有资源所有者许可的情况下发出access+token。|2918769|2918770|客户端请求访问令牌directly.|2918771|IdentityServer验证客户端并立即发出access+token。|2918772|2918773|当客户端也是资源所有者时，这是理想的，因此它不需要任何授权权限一直到access+token。|2918774|2918775|资源所有者流程：如果客户端拥有资源所有者的凭据(例如，Id+/密码)|2918776|2918777|客户端请求access+token+access+token验证客户端并检查资源所有者的身份。|2918778|如果有效，客户端将立即获取access+token。|2918779|2918780|对于您认为与其共享it和密码绝对安全的客户端来说，此流程是理想的。|2918781|2918782|混合流(OIDC流)：发出authorization+code和access+token。|2918783|这是Authorization+code+flow和Implicit+code+flow的组合。这就是它被称为Hybrid的原因。|2918784|2918785|自定义flow|2918786|从字面上看，这是一个可定制的流程。当您的业务中除了OAuth2中的所有协议规范之外，还需要特定的认证/验证流程时，可以使用该功能。|2918787|IdentityServer很清楚这种情况，并且它在设计上支持可扩展性。工厂模式、装饰器模式和IoC+/+DI将使您更容易在IdentityServer上实现其他功能。|2918788|entityMap|0|LINK|mutability|MUTABLE|url|https://www.rfc-editor.org/rfc/rfc6749|1|https://www.rfc-editor.org/rfc/rfc6749#section-4.1|2|https://www.rfc-editor.org/rfc/rfc6749#section-1.1^0|V|E|1D|C|2R|E|36|A|3H|F|0|6|0|22|H|1|49|4|2|0|0|0|5|9|I|V|C|0|0|J|0|0|0|5|J|0|0|W|I|0|0|E|I|0|0|5|C|U|C|0|0|0|0|5|C|C|T|I|0|0|1F|C|0|5|C|O|I|0|0|0|3|9|A|19|I|1S|C|0|0|0|N|14|C|0|0|0|O|C|0|0|Y|C|0|0|0|7|0|0|5|C|I|C|0|D|C|0|0|0|0|0|A|D|I|W|C|0|2|N|Q|I|1J|6|0|0|0|7|0|P|6|0|0^^$0|@$1|2|3|4|5|6|7|2O|8|@$9|2P|A|2Q|B|C]|$9|2R|A|2S|B|C]|$9|2T|A|2U|B|C]|$9|2V|A|2W|B|C]|$9|2X|A|2Y|B|C]]|D|@$9|2Z|A|30|1|31]|$9|32|A|33|1|34]|$9|35|A|36|1|37]]|E|$]]|$1|F|3|-4|5|6|7|38|8|@]|D|@]|E|$]]|$1|G|3|H|5|6|7|39|8|@$9|3A|A|3B|B|I]|$9|3C|A|3D|B|C]|$9|3E|A|3F|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|3G|8|@$9|3H|A|3I|B|C]]|D|@]|E|$]]|$1|L|3|M|5|N|7|3J|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|3K|8|@]|D|@]|E|$]]|$1|Q|3|R|5|N|7|3L|8|@$9|3M|A|3N|B|C]]|D|@]|E|$]]|$1|S|3|P|5|6|7|3O|8|@]|D|@]|E|$]]|$1|T|3|U|5|N|7|3P|8|@$9|3Q|A|3R|B|C]]|D|@]|E|$]]|$1|V|3|P|5|6|7|3S|8|@]|D|@]|E|$]]|$1|W|3|X|5|N|7|3T|8|@$9|3U|A|3V|B|C]]|D|@]|E|$]]|$1|Y|3|P|5|6|7|3W|8|@]|D|@]|E|$]]|$1|Z|3|10|5|N|7|3X|8|@$9|3Y|A|3Z|B|C]|$9|40|A|41|B|C]]|D|@]|E|$]]|$1|11|3|-4|5|6|7|42|8|@]|D|@]|E|$]]|$1|12|3|-4|5|6|7|43|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|44|8|@$9|45|A|46|B|I]|$9|47|A|48|B|C]|$9|49|A|4A|B|C]]|D|@]|E|$]]|$1|15|3|16|5|6|7|4B|8|@]|D|@]|E|$]]|$1|17|3|18|5|N|7|4C|8|@$9|4D|A|4E|B|C]]|D|@]|E|$]]|$1|19|3|1A|5|N|7|4F|8|@$9|4G|A|4H|B|C]|$9|4I|A|4J|B|C]]|D|@]|E|$]]|$1|1B|3|-4|5|6|7|4K|8|@]|D|@]|E|$]]|$1|1C|3|1D|5|6|7|4L|8|@$9|4M|A|4N|B|I]|$9|4O|A|4P|B|C]|$9|4Q|A|4R|B|C]|$9|4S|A|4T|B|C]]|D|@]|E|$]]|$1|1E|3|-4|5|6|7|4U|8|@]|D|@]|E|$]]|$1|1F|3|1G|5|6|7|4V|8|@$9|4W|A|4X|B|I]|$9|4Y|A|4Z|B|C]]|D|@]|E|$]]|$1|1H|3|-4|5|6|7|50|8|@]|D|@]|E|$]]|$1|1I|3|1J|5|N|7|51|8|@]|D|@]|E|$]]|$1|1K|3|1L|5|N|7|52|8|@$9|53|A|54|B|C]]|D|@]|E|$]]|$1|1M|3|-4|5|6|7|55|8|@]|D|@]|E|$]]|$1|1N|3|1O|5|6|7|56|8|@$9|57|A|58|B|C]]|D|@]|E|$]]|$1|1P|3|-4|5|6|7|59|8|@]|D|@]|E|$]]|$1|1Q|3|1R|5|6|7|5A|8|@$9|5B|A|5C|B|I]]|D|@]|E|$]]|$1|1S|3|-4|5|6|7|5D|8|@]|D|@]|E|$]]|$1|1T|3|1U|5|N|7|5E|8|@$9|5F|A|5G|B|C]|$9|5H|A|5I|B|C]]|D|@]|E|$]]|$1|1V|3|1W|5|N|7|5J|8|@$9|5K|A|5L|B|C]]|D|@]|E|$]]|$1|1X|3|-4|5|6|7|5M|8|@]|D|@]|E|$]]|$1|1Y|3|1Z|5|6|7|5N|8|@]|D|@]|E|$]]|$1|20|3|-4|5|6|7|5O|8|@]|D|@]|E|$]]|$1|21|3|22|5|6|7|5P|8|@$9|5Q|A|5R|B|I]|$9|5S|A|5T|B|C]|$9|5U|A|5V|B|C]]|D|@]|E|$]]|$1|23|3|24|5|6|7|5W|8|@$9|5X|A|5Y|B|C]|$9|5Z|A|60|B|C]|$9|61|A|62|B|C]]|D|@]|E|$]]|$1|25|3|-4|5|6|7|63|8|@]|D|@]|E|$]]|$1|26|3|27|5|6|7|64|8|@$9|65|A|66|B|I]]|D|@]|E|$]]|$1|28|3|29|5|6|7|67|8|@$9|68|A|69|B|C]]|D|@]|E|$]]|$1|2A|3|2B|5|6|7|6A|8|@]|D|@]|E|$]]|$1|2C|3|-4|5|6|7|6B|8|@]|D|@]|E|$]]]|2D|$2E|$5|2F|2G|2H|E|$2I|2J]]|2K|$5|2F|2G|2H|E|$2I|2L]]|2M|$5|2F|2G|2H|E|$2I|2N]]]]

The flows defined in <a href="https://www.rfc-editor.org/rfc/rfc6749" rel="nofollow noreferrer">OAuth2</a> are just several ways for a client to receive an <code>access token</code> from an identity provider server; the <code>IdentityServer</code> in this case. Understanding the flows won't be easy unless you fully comprehend the entities specified in <a href="https://www.rfc-editor.org/rfc/rfc6749#section-4.1" rel="nofollow noreferrer">the flow diagrams</a> such as <code>Resource Owner</code>, <code>User Agent</code>, and <code>Resource Server</code>. There're some brief explanations on these entities ( roles, preciously ) in <a href="https://www.rfc-editor.org/rfc/rfc6749#section-1.1" rel="nofollow noreferrer">here</a>.
<hr />
Authorization code flow : issues an <code>authorization code</code> prior to issuing an <code>access token</code>.
<ul>
<li>A client requests an <code>authorization code.</code></li>
<li>IdentityServer Validates the client and asks the resource owner to grant the authorization to issue an <code>authorization code</code>.</li>
<li>The client then requests an <code>access token</code> with the given <code>authorization code</code></li>
<li>The authorization server issues an <code>access token</code> directly to the client.</li>
</ul>
<hr />
Implicit code flow : issues an <code>access token</code> even with no <code>authorization code</code> provided.
<ul>
<li>A client requests an <code>access token</code> directly.</li>
<li>IdentityServer skips validating the client ( in some scenarios, it partially does ) but still asks the resource owner to grant the authorization to issue an <code>access token</code></li>
<li>This flow never issues an <code>authorization code</code>.</li>
</ul>
Implicit flow is considered as the ideal flow for a client using script languages like <code>javascript</code> since the client doesn't have to request for an <code>authorization code</code> and an <code>access token</code> separately, in turn, reducing one network round trip for the client.
<hr />
Client credentials flow : issues an <code>access token</code> without a resource owner's permission.
<ul>
<li>A client requests an access token directly.</li>
<li>IdentityServer validates the client and issues an <code>access token</code> right away.</li>
</ul>
This is ideal when the client is also a resource owner, so it doesn't need any authorization permissions all the way down to the <code>access token</code>.
<hr />
Resource owner flow : issues an <code>access token</code> if a client has the resource owner's credentials ( eg. Id / Password )
<ul>
<li>A client requests an <code>access token</code> directly.</li>
<li>IdentityServer validates the client and checks the resource owner's identity.</li>
<li>If valid, the client gets <code>access token</code> instantly.</li>
</ul>
This flow is ideal for the clients that you believe it is absolutely safe to share the ids and passwords with them.
<hr />
Hybrid flow (OIDC flow) : issues an <code>authorization code</code> and an <code>access token</code>.
This is a combination of <code>Authorization code flow</code> and <code>Implicit code flow</code>. That's why it's called <code>Hybrid</code>.
<hr />
Custom flow
This is literally a customizable flow. This can be used when you need a specific authentication / validation process in your business beside all the protocol specifications in <code>OAuth2</code>.
IdentityServer is well aware of this kind of situation and it supports extensibilities by design. The factory pattern, the decorator pattern, and IoC / DI will be making easier for you to implement additional features on your IdentityServer.

IdentityServer supports different OpenId Connect flows that are defined in the <a href="https://github.com/IdentityServer/IdentityServer3/blob/4a44a9f03879c85bbba50cc04c55fc4311436c1a/source/Core/Models/Enums.cs#L38-L69">Flows</a> enum and set for clients. There's also samples for each type of flow and many references to them in the docs but I could not find a simple definition list of what flows are in the <a href="https://identityserver.github.io/Documentation/docs/">documentation</a> as if they are too obvious to explain in words. But I guess they're not. Can you please tell more about the differences of these, maybe we can add that to the docs?

So what are: implicit flow, resource owner password credential flow, authorization code flow, client credentials flow, custom grant flow, and hybrid flow? Also which ones are OAuth flows and which ones are OpenID Connect flows?

Thanks!

IdentityServer Flows

身份验证

服务器

OAuth

IdentityServer支持不同的OpenId连接流，这些流在枚举中定义并为客户端设置。每种类型的流都有示例，并且在文档中有很多对它们的引用，但是我在中找不到流的简单定义列表，因为它们太明显了，无法用语言来解释。但我猜他们不是。你能多讲讲它们之间的区别吗?也许我们可以把它们加到文档中去？那么什么是：隐式流、资源所有...

问IdentityServer流
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问IdentityServer流EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问IdentityServer流
EN