Historically, web applications have implemented authentication and authorization in various ways. The history is described in this article. Usually, the process was similar to this one:
- A client sends a request to a web application, containing the username and password
- The web application looks up the two, and if there is a match, creates a session key and stores it in a response cookie
- Subsequent requests will then use the cookie and the contained session key to find out who the user is.
Applications today will usually do things a bit differently. First, web applications and web services shouldn't maintain their own list of users and their credentials. This will become more apparent when we start discussing microservices, but is true even for monolith applications. Second, not all clients use a cookie (only web clients do so).
There are several methods being used today to handle authentication and authorization, but we will mostly focus on OAuth and OpenID Connect.
The purpose of OAuth is described very well here:
"Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything.
Every day new websites launch offering services which tie together functionality from other sites. A photo lab printing your online photos, a social network using your address book to look for friends, and APIs to build your own desktop application version of a popular site. These are all great services – what is not so great about some of the implementations is their request for your username and password to the other site. When you agree to share your secret credentials, not only do you expose your password to someone else (yes, that same password you also use for online banking).
This is the problem OAuth solves. It allows you, the User, to grant access to your private resources on one site, to another site. While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your stuff without sharing your identity at all (or its secret parts)."
OAuth 1.0 was the first attempt at allowing users to grant access to their data to 3rd party applications. However, it had some issues, and many believe it should not be used today.
OAuth 2.0 attempted to replace 1.0 with a simpler protocol but ended up creating a loose framework that is very hard to implement securely. The lead author and editor claims that the OAuth 2.0 specification ended up being so poorly done and because of this he is no longer involved in the 2.0 effort and has withdrawn his name and support from it. He highly recommend you use OAuth 1.0 as 2.0 is likely to create security exploits.
This example explains the protocol workflow
Building an application in .NET which support OAuth is relatively easy.
Microsoft's ASP.NET Identity system is designed to replace the previous ASP.NET Membership and Simple Membership systems. It includes profile support, OAuth integration, works with OWIN, and is included with the ASP.NET templates shipped with Visual Studio 2013.
For example, when building a MVC 5 Application the support for enabling users to log in using OAuth 2.0 with credentials from an external authentication provider, such as Facebook, Twitter or Google is already supported out of the box. This tutorial explains how
Futher more, this tutorial exaplains how to create your own OAuth 2.0 Authorization Server using OWIN OAuth middleware
Links
##OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the 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.
OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of “making simple things simple and complicated things possible”. It's uniquely easy for developers to integrate, compared to any preceding Identity protocol.
OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. For the app builder, it provides a secure verifiable, answer to the question: “What is the identity of the person currently using the browser or native app that is connected to me?”
OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.
(Identity, Authentication) + OAuth 2.0 = OpenID Connect
What OpenID Connect does is basically add authentication on top of OAuth.
One could say that the main difference between these protocols is that OAuth defined access tokens, these tokens are then used to access providers, for example get some information from facebook/google. On the other hand OpenID Connect defined identity tokens which are used to identify the user, for example to access an application.
The OpenID Connect protocol, in abstract, follows the following steps.
- The Client sends a request to the OpenID Provider.
- The OpenID Provider authenticates the End-User and obtains authorization.
- The OpenID Provider responds with an ID Token and usually an Access Token.
- The Client can send a request with the Access Token to the UserInfo Endpoint.
- The UserInfo Endpoint returns Claims about the End-User.
This video explains the basics of the protocol
Also, this video, which is a talk by Dominick Baier held at the 2014 NDC explains the differences between OpenID Connect & OAuth in an interest way. You are encouraged to watch it!
OAuth 2.0, is a framework, specified by the IETF in RFCs 6749 and 6750 (published in 2012) designed to support the development of authentication and authorization protocols. It provides a variety of standardized message flows based on JSON and HTTP, OpenID Connect uses these to provide Identity services.
There are several libraries available in different languages that implement OpenID Connect and related specifications.
One of these libraries is the IdentityServer v3 which is demonstrated in the talk by Dominick Baier
IdentityServer v3 is a .NET-based open source implementation of an OpenID Connect and OAuth2 security token service.
###OpenID Connect basic specs
####Flows
The OpenID Connect authentication process consists by requiring the user to authenticate him/her self through a OpenID provider. This process then returns the information about the user in the form of an id token, which contains scopes and claims, as well as other useful information about the user being authenticated.
The way in which this process is conducted is referred as a flow. The main flows are:
- Code Flow
- Implicit Flow
- Hybrid Flow
This flow can be specified through the 'response_type' parameters in the authorization request.
#####Code Flow
The basic steps of this flow are the following:
- The client sends an authentication request to the OpenID provider.
- The OpenID provider authenticates the user (on behalf of the client) and responds with an authorization code to the client.
- The client requests an id token with the authorization code.
- The client validates the token and retrives the user information.
The basic steps of this flow are the following:
- The client sends an authentication request to the OpenID provider.
- The OpenID provider authenticates the user (on behalf of the client) and redirects him/her to the client with an id token.
- The client validates the token and retrieves the user information.
#####Hybrid Flow
This flow is basically a mix of the other two, which means that in some cases the authorization process is return to the client with a code and sometimes with an id token directly.
####Request Parameters
Some of the request parameters or main ones are:
- client_id : This is the client identifier.
- response_type : this is the reponse type. Like 'id-token' or token.
- scope : This represents the access or information request. F.e. openid, profile, email, read or write.
- redirect_uri : This is the location for where the response will be sent.
- response_mode : This defines the Form Post Response Mode.
- state : This is for maintaining a state between the client and provider.
- nonce : This is used to associate a client session with an id token.
As we talked about earlier the id token contains information about the authenticated user in the form of a claim. Id tokens as represented in a JSON Web Token format. Some of the claims contained within an id token are the following:
- iss : This represents the issuer of the response (url).
- sub : This is the subject identifier, a unique identifier that represents a user.
- aud : This is the audience which is a client identifier.
- exp : This represents the expiration date of the id token.
- iat : This represents the issue date.
- nonce : Again, this is used to associate a client session with an id token.
- at_hash : This represents the hashed access token.
####Scopes
OpenID Connect defines the following scope values:
- openid : This represents the authorization request
- profile : This represents a profile claim request
- email : This represents an email claim request
- address : This represents an address claim request
- phone : This represents a phone claim request
- offline_access : This represents an OAuth 2.0 Refresh Token request
It is of course also possible to define custom scopes in order to achieve some functionality.
####Claims
The OpenID Connect also defines several sets of claims. For more information on Claim please refer to these specs.
####Comparison between OAuth and OpenID
This wiki link compares OAuth and OpenID and also has a simple picture which explains the differences in the processes. [OpenID vs pseudo-authentication using OAuth] (http://en.wikipedia.org/wiki/OAuth#OpenID_vs._pseudo-authentication_using_OAuth)
Links