IdentityServer Flows

Question

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

Answer 1

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

http://openid.net/specs/openid-connect-core-1_0.html and http://tools.ietf.org/html/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/

Answer 2

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

Answer 3

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.

Answer 4

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.