Creating your own OpenID Connect server with ASOS: choosing the right flow(s)

Development

This post is the second part of a series of blog posts entitled Creating your own OpenID Connect server with ASOS:

  1. Introduction
  2. Choosing the right flow(s)
  3. Registering the middleware in the ASP.NET Core pipeline
  4. Creating your own authorization provider
  5. Implementing the resource owner password credentials grant
  6. Implementing the authorization code and implicit flows
  7. Adding custom claims and granting scopes
  8. Testing your authorization server with Postman
  9. Conclusion

ASOS offers built-in support for all the standard flows defined by the OAuth2 and OpenID Connect core specifications: the authorization code flow, the implicit flow, the hybrid flow (which is basically a mix between the first two flows), the resource owner password credentials grant and the client credentials grant.

Though not specific to ASOS, choosing the best flow(s) for your application is an important prerequisite when implementing your own authorization server ; so here's a quick overview of the different OAuth2/OpenID Connect flows:

Non-interactive flows

Resource owner password credentials flow

Directly inspired by basic authentication, the resource owner password credentials grant (abbreviated ROPC) is probably the simplest OAuth2 flow: the client application asks the user his username/password, sends a token request to the authorization server with the user credentials (and depending on the client authentication policy defined by the authorization server, its own client credentials) and gets back an access token it can use to retrieve the user's resources.

1
2
3
4
5
POST /connect/token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w
1
2
3
4
5
6
7
8
9
10
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"bearer",
  "expires_in":3600
}

Though not recommended by the OAuth2 specification as it's the only flow where the user password is directly exposed to the client application (which breaks the principle of least privilege), the resource owner password credentials grant is one of the most popular flows.

It is is particularly appreciated by SPA writers as it's trivial to implement in vanilla JavaScript, doesn't involve any redirection or consent form and, unlike interactive flows, doesn't require implementing token validation or cross-site request forgery (XSRF) countermeasures to prevent session fixation attacks.

If you don't feel comfortable with the other flows (and the security measures they require on the client-side), using ROPC might be a good option: paradoxically, a client application using ROPC will be far less vulnerable than a client using interactive flows without implementing the appropriate security checks.

As recommended by the OAuth2 specification, you SHOULD NEVER use it with third-party applications. If you want to support applications you don't fully trust, consider using an interactive flow instead (e.g authorization code or implicit flow).

Read more

Creating your own OpenID Connect server with ASOS: introduction

Development

This post is the first part of a series of blog posts entitled Creating your own OpenID Connect server with ASOS:

  1. Introduction
  2. Choosing the right flow(s)
  3. Registering the middleware in the ASP.NET Core pipeline
  4. Creating your own authorization provider
  5. Implementing the resource owner password credentials grant
  6. Implementing the authorization code and implicit flows
  7. Adding custom claims and granting scopes
  8. Testing your authorization server with Postman
  9. Conclusion

What's ASOS?

AspNet.Security.OpenIdConnect.Server (codenamed ASOS) is an open-source OAuth2/OpenID Connect server middleware for OWIN/Katana and ASP.NET Core 1.0 (previously known as ASP.NET 5), designed to work on both the full .NET desktop framework and the new .NET Core platform. It is part of the aspnet-contrib initiative, that's also behind the OAuth2 social providers for ASP.NET Core.

Forked from Katana's now deprecated OAuth2 authorization server middleware, ASOS shares the same same low-level, protocol-first approach but comes with many new OpenID Connect features (e.g provider configuration discovery, client-initiated logout or userinfo support) and implements some of the recent OAuth2 specifications like token revocation or token introspection (kudos to Michael Ciarlillo for his great contribution!).

How is it different from the other identity servers?

Unlike other identity server projects, ASOS only focuses on the OAuth2/OpenID Connect protocol part and acts as a thin layer between your application and the protocol details: it comes with no membership feature, implementing the consent pages is left as an exercise and adding a CORS policy must be done by the developer depending on his/her own needs.

Though it requires a solid knowledge of the OAuth2/OpenID Connect specifications and generally needs more work than turnkey solutions (like the famous IdentityServer or OpenIddict), ASOS offers the most flexible approach and can be easily integrated to any existing environment.

Read more