This post is the first part of a series of blog posts entitled Creating your own OpenID Connect server with ASOS:
- Introduction
- Choosing the right flow(s)
- Registering the middleware in the ASP.NET Core pipeline
- Creating your own authorization provider
- Implementing the resource owner password credentials grant
- Implementing the authorization code and implicit flows
- Adding custom claims and granting scopes
- Testing your authorization server with Postman
- Conclusion
What's ASOS?
AspNet.Security.OpenIdConnect.Server (codenamed ASOS) is an open-source OAuth 2.0/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 OAuth 2.0 social providers for ASP.NET Core.
Forked from Katana's now deprecated OAuth 2.0 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 OAuth 2.0 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 OAuth 2.0/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 OAuth 2.0/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.
Is ASOS the right tool for me?
If you're not comfortable at all with how OAuth 2.0 or OpenID Connect work in general, then no, ASOS is probably not for you. Like OAuthAuthorizationServerMiddleware
, ASOS has been designed as a low-level framework rather than as a ready-to-use server: you can't use it without providing your own authorization logic or without implementing the different flows you want to support.
Of course, ASOS handles most of the protocols details for you (e.g request validation, provider discovery, token serialization/deserialization), so the effort needed to implement the missing parts is actually limited to very precise things like client authentication or consent form pages: you don't need to be a security expert to use ASOS.
What about OpenIddict?
Based on ASOS, OpenIddict is a whole new OpenID Connect server designed to offer a simpler solution to most token authentication scenarios. It natively supports all the OAuth 2.0/OpenID Connect flows and includes built-in request validation routines. Only user authentication/consent is left as an exercise, which can be done quite easily by adding a custom AuthorizationController
MVC controller in your application, similarly to the approach used by ASP.NET Core Identity with its AccountController
.
Though still at an early stage, OpenIddict is probably your best option if you're looking for a simple/easy-to-use server, that easily integrates with the rest of your ASP.NET Core application. Conversely, if you think you need more flexibility or if you want to have full control over the entire OpenID Connect process, then ASOS is definitely for you.
For more information about OpenIddict, don't miss these interesting blog posts/books:
- Bearer Token Authentication in ASP.NET Core by Mike Rousos (for the Microsoft .NET Web Development and Tools blog)
- Token authentication with OpenIddict in ASP.NET Core 1.1 by Medhat Elmasry
- Implementing simple token authentication in ASP.NET Core with OpenIddict by Kévin Chalet
How is this blog posts series organized?
For better readability, this series was split into 7 posts – from the most general to the most specific – and will almost exclusively cover the server-side aspects of building your authorization server based on ASOS:
- Choosing the right flow(s)
- Registering the middleware in the ASP.NET Core pipeline
- Creating your own authorization provider
- Implementing the resource owner password credentials grant
- Implementing the authorization code and implicit flows
- Adding custom claims and granting scopes
- Testing your authorization server with Postman
Next part: Choosing the right flow(s).