57

IdentityServer supports different OpenId Connect flows that are defined in the Flows 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 documentation 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!

orad
  • 15,272
  • 23
  • 77
  • 113

4 Answers4

41

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:

Enrich IdentityServer Documentation with OIDC and OAuth2 Flows section #73

Update: OIDC and OAuth2 Flows

orad
  • 15,272
  • 23
  • 77
  • 113
Jawad Al Shaikh
  • 2,475
  • 2
  • 28
  • 41
  • 5
    Also see this [introduction to OAuth 2.0](https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2) by DigitalOcean. – orad May 02 '16 at 18:52
24

From leastPrivilage's first link: and Aharon Paretzki's OAuth 2 Simplified

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

  • an Authorization Code is returned from the Authorization Endpoint
  • and all tokens (as a second stage, in exchange for the authorization code) are returned from the Token Endpoint
  • 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".

Implicit Flow: OAuth 2.0 flow in which

  • all tokens are returned directly from the Authorization Endpoint
  • and neither the Token Endpoint nor an Authorization Code are used.
  • 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.

Hybrid Flow: OAuth 2.0 flow in which

  • an Authorization Code is returned from the Authorization Endpoint,
  • 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.
  • Used where both flows are needed.
pashute
  • 3,965
  • 3
  • 38
  • 65
12

see the specifications - it has been all written down already:

http://openid.net/specs/openid-connect-core-1_0.html and https://www.rfc-editor.org/rfc/rfc6749

in addition i've recently written a summary that breaks it down for different application types:

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

Community
  • 1
  • 1
leastprivilege
  • 18,196
  • 1
  • 34
  • 50
  • 2
    I know but I was looking for a shorter description. I found [this](http://leastprivilege.com/2014/10/10/openid-connect-hybrid-flow-and-identityserver-v3/) description in your blog very useful. – orad Apr 16 '15 at 21:10
  • 3
    I also find this is the biggest problem with Identity Server in that there's limited basic information about the product. A month or so into implementing the framework the extremely detailed docs will prove useful but the learning curve isn't steep it's vertical. – Dillorscroft Nov 12 '15 at 00:20
  • 1
    I've actually learnt more about Identity Server through Auth0.com implementation docs and then coming back to Identity Server. – Dillorscroft Nov 12 '15 at 00:22
  • There also a gaping whole in the docs on how this fits in with native mobile apps. I intend to implement with Xamarin and blog my findings. – Dillorscroft Nov 12 '15 at 00:25
  • 4
    Feel free to write that all up and let us know so we can link to it. It is not a product, it is OSS. Moaning is easy. Improve it yourself. – leastprivilege Nov 12 '15 at 07:43
  • 3
    You're right. I shouldn't moan. It's a great resource, hope I can contribute. – Dillorscroft Nov 15 '15 at 22:15
  • IdentityServer is one of the best documented projects I have worked with. There are dozens of easy to follow examples here https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source. Thanks @leastprivilege ! – Rob L Jan 20 '17 at 09:48
8

The flows defined in OAuth2 are just several ways for a client to receive an access token from an identity provider server; the IdentityServer in this case. Understanding the flows won't be easy unless you fully comprehend the entities specified in the flow diagrams such as Resource Owner, User Agent, and Resource Server. There're some brief explanations on these entities ( roles, preciously ) in here.

Authorization code flow : issues an authorization code prior to issuing an access token.

  • A client requests an authorization code.
  • IdentityServer Validates the client and asks the resource owner to grant the authorization to issue an authorization code.
  • The client then requests an access token with the given authorization code
  • The authorization server issues an access token directly to the client.

Implicit code flow : issues an access token even with no authorization code provided.

  • A client requests an access token directly.
  • IdentityServer skips validating the client ( in some scenarios, it partially does ) but still asks the resource owner to grant the authorization to issue an access token
  • This flow never issues an authorization code.

Implicit flow is considered as the ideal flow for a client using script languages like javascript since the client doesn't have to request for an authorization code and an access token separately, in turn, reducing one network round trip for the client.

Client credentials flow : issues an access token without a resource owner's permission.

  • A client requests an access token directly.
  • IdentityServer validates the client and issues an access token right away.

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 access token.

Resource owner flow : issues an access token if a client has the resource owner's credentials ( eg. Id / Password )

  • A client requests an access token directly.
  • IdentityServer validates the client and checks the resource owner's identity.
  • If valid, the client gets access token instantly.

This flow is ideal for the clients that you believe it is absolutely safe to share the ids and passwords with them.

Hybrid flow (OIDC flow) : issues an authorization code and an access token.

This is a combination of Authorization code flow and Implicit code flow. That's why it's called Hybrid.

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 OAuth2.

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.

Community
  • 1
  • 1
hina10531
  • 3,938
  • 4
  • 40
  • 59