The OpenID Connect Specification extends OAuth2 in a number of ways, one of which is to define some new Response Types that can be used. Unfortunately it doesn’t do the best job in explaining what these all mean. It actually is explained, if you know where to look, but even then it’s not the clearest document in the world.

Part of the complexity is that the specification allows for combinations of response types, but doesn’t make this as obvious as it could. Instead it makes it look like the combinations are actually whole new response types in their own right, which isn’t quite right.

The actual set of response types are:

• code - The requester would like an Authorization Code to be returned to them
• token - The requester would like an Access Token to be returned to them
• id_token - The requester would like an ID Token to be returned to them
• none - The requester doesn’t want any of the above to be returned to them

The “none” response type is a special case in that it can not be combined with any of the others. The other three can be combined in any way that you want, and you will be requesting all of the details for the combination that you specify. For example:

• code token - The requester would like both an Authorization Code and an Access Token to be returned to them
• token id_token - The requester would like both an Access Token and an ID Token to be returned to them
• code token id_token - The requester would like an Authorization Code, an Access Token and an ID Token to be returned to them

The further confusion is in the fact that the specification will allow these to be combined in any order, but you will almost always see them in the same order in the various documents. The requests for “code token id_token”, “code id_token token” and “token id_token code” are all actually the same, and should be treated as such.

So why would you want to combine these? The obvious reason is because of the OpenID Connect Implicit Flow and OpenID Connect Hybrid Flow requiring it. Implicit allows for the client to specify either “id_token” or “id_token token”, and Hybrid allows for the client to specify either “code id_token”, “code token”, or “code id_token token”.

The uses of “id_token token” and “code id_token” are fairly straightforward - they allow for the client to get the ID Token directly and also get an Access Token - either directly or indirectly - to further make API calls to the server. The use of “code token” and “code id_token token” is slightly less obvious - why would you want to get the Access Token AND an Authorization Code, when the only use of an Authorization Code is to swap it for an Access Token? The reason is that an Authorization Code actually does get you more than an Access Token. It also gets you a Refresh Token, which gives you much longer term access to the resources on the server than the Access Token on it’s own likely will.

TDD, or Test Driven Development, is fairly well acknowledged to be a great idea. The general theory behind it is that you write your tests first, which will initially fail, and then you write just enough code to make the tests pass. Once the tests pass, the code is finished and you can move on to the next bit of functionality. There have been studies done that show that working this way drastically reduces the number of issues in the overall product.

And for some languages, this is all fantastic. You write the tests, the tests fail, you move on to the actual development.

And for yet other languages, this just doesn’t work at all. Specifically I’m thinking compiled, statically typed languages here. The problem with this scenario is, when you write your tests against non-existent types then you break the compilation of the test suite, which in turn breaks every test in the system. And that in turn means that until you’ve implemented at least enough for all of the tests to compile you can’t be sure that you’ve not broken anything else.

Read More

HATEOAS, for anyone who’s not come across it yet, is an additional constraint added on top of normal REST services whereby the only way that clients ever interact with the server is through Hypermedia that the server provides. The server will provide a single starting point, and every single interaction with the server after that is made only through URLs that the server has previously provided to the client. The advantage here is that the server can change independently of the client, and as long as the client only ever follows the URLs provided to it then everything will continue to work correctly.

That all sounds fantastic on the face of it. Completely decoupled evolution of server and client sounds almost idyllic.

Of course, in reality this doesn’t actually work. There are a number of problems with the idea, ranging from the very simple - clients cut corners and just hard-code URLs to specific resources instead of following links - to the very complicated, where changes to the server need to be made that just aren’t backwards compatible.

Read More

I’ve just gone through some of the reasons that I don’t like the Relay API requirements for GraphQL, so lets have a go at designing an API that I do like.

Read More

I’ve started playing with GraphQL again recently, having been looking into various other specifications for HTTP based APIs, and I’ve come to a conclusion. I really like GraphQL, but I don’t like Relay.

Now, don’t get me wrong, there are bits of Relay that I think are really good ideas. But there are also bits that I just think are either a waste of time, or worse actually make the API harder to use.

Read More

Having just had a very brief overview of GraphQL, the next thing that might be of interest is Relay. Relay in this sense means one of two things. Either it means the Relay Javascript Framework that is used in your frontend layer to communicate with a GraphQL Server, or - and this is what’s more interesting to myself right now - it means the set of concepts that your GraphQL Server needs to adhere to in order for it to be Relay Compatible.

Read More

You may or may not have already come across GraphQL by now. GraphQL is a new concept coming out of the software people at Facebook, and like their other ideas recently - React and Flux mainly - it looks like it could really change the way we think about our HTTP based API design.

So, what is it exactly? And why is it a big deal?

Read More

If you didn’t know, CORS - or Cross-Origin Resource Sharing - is a W3C specification for allowing a page loaded from one domain to access resources on a different domain via XMLHttpRequest calls. This is important for a number of reasons, but the main one for me right now is because it means that you can split your application into multiple smaller services - microservices - that are hosted on different subdomains and still access them all from your Javascript.

Read More

For a long time, one of the big problems I’ve had with NodeJS is that of Unit Testing. Specifically with the fact that, by definition, a Unit Test is testing a single unit in complete isolation of the rest of the world. In Node terms, a Unit would be a single Module.

Read More

MongoDB has a lot of good things about it, and equally a lot of bad things about it. This is true of most database engines though, and you need to know what you’re looking at to be able to make a good call over which system to use for what you’re doing.

Optimistic locking is traditionally quite difficult to achieve. You need to ensure that the version in the database matches the version in the update request, and fail if that’s not the case. There are a few ways of achieving this, but often with risks and race conditions involved.

Read More