It’s been around 12 months since the completion of the long awaited OAuth 2.0 specification so it’s as good a time as any to look at how we, as developers, could take advantage of it.
This post introduces the main actors, some terminology and two scenarios in which you might find OAuth useful. In later posts I’ll show how to implement common scenarios enabled by Azure and tools available on NuGet.
What is OAuth 2.0?
- OAuth is an authorization framework not an authentication tool. There must necessarily be an authentication component to ensure access is only provided to the correct client, but this part isn’t well defined by the specification.
- OAuth is a framework, not a protocol. The lack of implementation detail means OAuth providers are not interoperable.
- It relies on providing an access token, also called bearer token, to a client so that the client may gain access to a protected resource.
- There are five defined ‘grants’, which are means to obtain an access token.
Resource Server – This hosts the resource you are trying to protect. It can be an API as in the case of the Twitter API or Facebook Graph but it doesn’t need to be.
Resource Owner – This is who owns the resource. For example, you are the resource owner of the information you upload to Facebook and people are not allowed to view it unless you grant them permission.
Client – This is the application which wants to access the resource. It can be native application, a stand-along web service or a web site acting through a user-agent.
User-Agent – Typically a browser but not required in all scenarios.
Authorization Server – This brokers the authorization. The resource server will only trust clients which have been authorized by the auth server.
Terminology and Tools
Grant – There are five OAuth 2 grants specified. Each one describes a different means to grant a client application access to the resource server.
Tokens – Tokens carry information between the actors. There are different types of tokens which fulfil different needs but the end goal is to get an access token, typically in JWT format.
Active Directory Authentication Library (ADAL) – This abstracts the hairy OAuth details so that you can query the resource server and secure a resource using only a few lines of code. Handy.
Windows Azure Active Directory (WAAD) – This is the cloud implementation of Active Directory. ADAL also works with AD/ADFS but I will be using WAAD because it’s free and less effort that setting up Active Directory.
Two Typical OAuth 2.0 Scenarios
Delegating access to a client application
This is the type of authorization grant that most people are most familiar with; it requires the user to enter their credentials and optionally provide consent to access a resource. For example, I might create a client application which needs to know who your friends are on Facebook. When required, you authorize the app by logging into Facebook (this is the authentication part) and clicking ‘Okay’ on a dialog which says something like “Adam’s Client Application would like to access your friend list.” This shown in the “authorization code grant” example.
Trusting a client’s credentials
Sometimes there is no end-user to provide a grant; your client may be a web service which periodically need access to the resource server. You can grant access to the client based on a unique client identifier paired a client secret. This is the client credential grant.