pretty sure you all have seen the Twitter “authorize app” page before (see Figure 1).
Figure 1 Twitter consent dialog
Once the client has requested the access token, it can use it access the user’s backend data (like his tweets). This approach has a number of benefits – the user does not need to type his passwords into a partially trusted client and the client developer does not need to deal with the password at all (which would typically include storing the password on the client device which is potentially not very well secured).
I heard OAuth2 is insecure?! OAuth2 is a very controversial topic. Part of the reason is the fact that the original creator and lead editor of the spec left the project and withdrew his name from all documents. Another reason is that a number of “big” implementations have recently been hacked. The truth is that the specification document is not really helpful in guiding people how to create secure implementations of OAuth2 and that’s what happened to Facebook and the like. I discussed the pros and cons in two blog posts I wrote - [3] and [4]
specific clients again (without having to change the password). So in other words OAuth2 describes the message format and interactions between the client, the authorization server and the resource server for various application types. OAuth2 is specified in the RFC 6749 and 6750. Whoever wants to learn more about it should at least read these documents [0] but in addition the book “Getting started with OAuth2” [1] as well as the corresponding threat model [2] have lots of good information. JSON WEB TOKEN (JWT) I mentioned identity and access tokens – they are in essence data structures describing resource owners, clients as well as data and operations a client has access to. The content of the token is up to the issuer. Unfortunately the OAuth2 spec also did not mandate a specific token type, which lead to a number of sub-optimal homegrown implementations. JSON Web Tokens (JWT) though are becoming the de-facto standard for tokens because they are reasonable simple to create, parse and validate and the fact that they are basically signed JSON data structures makes them easy to handle in almost all programming languages. A JWT consists of two parts – a header providing some metadata as well as claims. Claims come in two flavors – reserved ones like issuer or expiration as well as provider specific ones like roles: {
} {
}
Instead the access token gets stored on the client, which allows users to change their password for the backend service without breaking existing clients as well as revoking access for
52
"typ": "JWT", "alg": "HS256"
"iss": "http://myIssuer", "exp": "1340819380", "aud": "http://myResource", "name": "alice", "role": "foo,bar",
For wire transmission you base64 encode the two parts and create a signature of those strings separated by a dot, e.g.:
eyJhbGciOiJub25lIn0.eyJpc3MiOiJq b2UiLA0KICJleHAiOjEzMD.4MTkzODAs DQogImh0dHA6Ly9leGFt
You can find the specification for JWTs at [5] and Microsoft’s ready to use .NET implementation at [6]. A handy tool during development is the JWT debugger, that can be found at [7]. OpenID CONNECT I said earlier that OAuth2 is about authorization, or in other words, the client requests a token for a backend service. This token is typically opaque for the client and makes only sense in the context of the backend service it was issued for. But what if a client needs to validate the identity of a user, e.g. to provide personalization as well as access control to application functionality. In that case OAuth2 on its own is not enough (in fact some naïve approaches are inherently insecure – see [8]). OpenID connect defines the additional concept of an identity token, a token that describes user identity to a client (also called relying party in their lingo). In contrast to authorization (which is very application specific), authentication protocols must be interoperable to be really useful. As a result, the OpenID Connect specification is also much stricter in the definition of message layouts and content as well as token formats (namely JWT) to give us the needed pluggability. OpenID Connect is the next version of the “classic” OpenID and is designed to be more API friendly; it is very close to “RTM” and you can read about the various flows at [9]. SUMMARY The purpose of this article was to introduce you to the security relevant mechanisms in (modern) Web API communication and to make it easier to pin point which technology serves which purpose. My simple rule of thumb is: when a client requests a token for a backend, that’s authorization and OAuth2 is used for that. Does the client request