Authentication and Authorization have never been an easy topic for me. Right from ASP.NET Membership, I've tried to grasp the ins and outs of this topic, but its tight coupling of roles and permissions within the actual code bothered me constantly. I was always thinking of taking this tight coupling out of the actual code and make it configurable such that we can dynamically create different roles with our desired set of permissions. Moreover, another downside was that whenever implementing our own membership, a lot of custom code has to be written.
Until the recent release of ASP.NET Identity where authentication and authorization is claims-based, it turned out that I was not the only person thinking about it rather the whole .NET community was concerned about it. This release, as mentioned by Microsoft, is majorly based on community feedback. We'll see the details of claims based authentication and authorization in this blog later.
Beside the community feedback the current diversity of applications/platforms and the need for OWIN middleware support was also a driver for Microsoft to move to a new authentication and authorization framework. Let's first see how many different scenarios we have for authentication in modern world applications.
Modern World Authentication Scenarios
Web APIs have significantly changed our architectural strategy and there has been a design shift from traditional services to modern RESTful services and Web APIs. Moreover SPAs (Single Page Applications) and many other UI frameworks are growing to support RESTful services and Web APIs. So keeping in view this we have following possible scenarios in modern world authentication:
- Web Applications/SPAs communicates with Web APIs
- Web APIs communicate with Web APIs
- Native Clients/Mobile Apps communicate with Web APIs
- Desktop/Server Applications communicate with Web APIs
Source: The Big Picture
Now each of these nodes has to implement authentication and authorization in order to protect their resources. And normally this authentication and authorization is being done against the same user store (either Active Directory, Database or Online Identity provider).
And since we normally avoid duplicated logic/code in our software, so a better approach would be to outsource this critical authentication and authorization logic in a separate service, which would then be utilized in all these nodes. This is where authentication server comes in.
Authentication Server and Token Based Authentication
The authentication server provides a service over network which can be used by applications/services to authenticate their users through usernames and passwords. When a client submits valid credentials, it receives a cryptographic ticket/token that it can subsequently use to access various resources/services. So in this way, our identity information is basically floating on all these nodes securely.
Authentication is used as the basis for authorization, which is the determination whether a privilege may be granted to a particular user or process, privacy, which keeps information from becoming known to non-participants.
The benefit includes:
- Centralized authentication and authorization mechanism. No need to replicate the logic into multiple applications
- Developers don’t need to worry about authentication and authorization and can focus on application logic only
- Change in authentication logic does not affect the underlying applications
- High availability is required since multiple applications rely on the same authentication service
Benefits of Token Based Authentication
With the emergence of APIs in web technology, token become the best way to authenticate and authorize in such stateless environments. There are multiple benefits of token based authentications like stateless, scalable, secure, extensible, multi-platform support etc.
It performs better in scenarios like stateless and scalable servers, mobile applications support, pass authentication to other applications and extra security.
See Ins and Outs of Token based Authentication for details.
The usage of Authentication Server with Token Based authentication leads to following usage of security protocols.
Source: The Big Picture
Let's discuss some of these protocols.
OAuth is an open standard for authorization. OAuth provides client applications a secure delegated access to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner, or end-user. The client then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.
Here are the specifications of OpenID Connect protocol
OpenID Connect and OAuth2 – better together
OpenID Connect and OAuth2 are very similar – in fact OpenID Connect is an extension on top of OAuth2. This means that you can combine the two fundamental security concerns – authentication and API access into a single protocol – and often a single round trip to the security token service.
What are Claims?
ASP.NET Identity supports claims-based authentication, where the user’s identity is represented as a set of claims. Now let's talk about Claims, as this is the basis of how ASP.NET Identity is being designed. Claim is a piece of identity information such as name, email, age, membership in sales role. Each claim is made by issuer (authentication server). More claim you get, more you know about the user. Below are few common examples of claims in the form of statements
- Umair’s email address is firstname.lastname@example.org
- Anis’s full name is Anis Ahmad
- Shahid can assign tasks
- Adil is an Admin
Why Claim based authorization is flexible?
Claims allow developers to be a lot more expressive in describing a user’s identity than roles allow. Whereas role membership is just a boolean (member or non-member), a claim can include rich information about the user’s identity and membership. Moreover authorization logic is not hard coded and can be modified through some admin interface. We only describe the required claim for a particular action in code and this claim can be assigned to anyone through some UI. So in this way permissions can be set at more granular level as compared to role based authorization.
Thinktecture Identity Server
I was recently involved in a project where we were in need to expose our tools as services to our clients. Each of these tools was a complete application using its own Web APIs. All these services and underlying Web APIs were required to be authenticated through a single user store (a database) through authentication server.
We decided to use OpenID Connect Provider which implements OpenID for authentication and OAuth2 for authorization. Since we were inclined towards .NET implementation only, Thinktecture Identity Server was the only certified implementation available. Beside being open source, it has many other benefits and features.
Benefits and Features
- Supports multiple clients including web, mobile, native and desktop clients
- Supports multiple authentication providers, including:
- ASP.NET Identity
- Entity Framework
- Membership Reboot
- WS-Federation support
- Supports external identity providers, including:
- It’s an open source project which can even be customized through available code in GitHub
- It has some other associated tools as well:
- Identity Manager: This is a UI layer on top of identity server, which can be used to manage user identities
- Identity Model: A useful extension for claim based authorization using Thinktecture
Our implementation of Thinktecture Identity Server
The detail of how we implemented Authentication Server using Thinktecture Identity Server will be provided in Part 2 of the same series.