On my current project we are using OAuth 2.0 and OpenID Connect for securing our Web APIs. I have used OAuth in the past, but OpenID Connect was something new to me, so I decided to get a deeper understanding of these two protocols. In my search for a good book on the subject, I’ve found Advanced API Security: Securing APIs with OAuth 2.0, OpenID Connect, JWS, and JWE by Prabath Siriwardena. As the title says, it’s about OAuth and OpenID Connect. But, while I was skimming the book I noticed that it’s about more than that, as it presents the evolution of different security protocols. The book looked promising so I decided to read it and I must say that I have gained a lot from it. It provides a good overview of the most important topics on API Security.
If you ask a hundred developers to define software quality, you’ll probably get a hundred different answers. There are a lot of ways to categorize quality, but one that I find most useful is building the right product and building the product right.
Building the Right Product
First we have to make sure we are building the right product. The most performant and secure product, having the cleanest and most extensible architecture, covered with unit tests and acceptance tests is in vain if nobody uses it.
In their book, Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck define this dimension of quality as the perceived integrity of a product. Perceived (external) integrity means the totality of the product achieves a balance of function, usability, reliability, and economy that delights customers.
Traditionally, when customers want to build a product, they talk with business analysts and write down the requirements. These documents are then handed over to architects, who then define the high level architecture and pass the design documents down to programmers who start implementing. There’s a gap between each step and as we go through the process, we lose more and more information and our chances of building the right product get slimmer.
Writing good tests is hard. Writing good specification is even harder. On my current project we treat test code with the same care we treat production code (which should be the norm on all projects), but we could still improve the readability, reliability and maintainability of our test suite.
With this in mind, Fifty Quick Ideas to Improve Your Tests by Gojko Adzic, David Evans and Tom Roden was the perfect choice for our book reading club. I’ve previously read Gojko’s Specification by Example, which really helped me better understand BDD and how to use it in practice, so I had high hopes for this book.
In the previous post we talked about delegated authorization with OAuth 2.0. After the success of OAuth 2.0, many companies tried using OAuth as an authorization method, which has known pitfalls. The main issue is that if a malicious application manages to steal an access token, it can use it to impersonate the user. Many OAuth 2.0 providers modified the OAuth protocol to implement authorization, which made them less interoperable and possibly even vulnerable to impersonation attacks. Since OpenID was an existent standard for federated identity, there was interest in combining these two protocols, so the third generation of the OpenID protocol was built as an OAuth 2.0 extension.
OpenID Connect is an identity layer built on top of OAuth 2.0. It specifies a RESTfull HTTP API that is interoperable (it uses JSON as the data format), simple, mobile friendly and secure.
Since identity is an overloaded term, OpenID Connect defines identity as a set of claims (attributes) related to a an entity (person, service, machine).