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.
Security
OpenID Connect in a nutshell
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
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).
Continue Reading
OAuth 2.0 in a nutshell
Let’s say you’re developing a SOA application. The user interface is a website that needs to be accessible from the public internet. You are using service composition in the UI, so you have JavaScript components from each service deployed in the UI. These components talk with their corresponding Web API over HTTP. Since the Web APIs are public facing, they’re sitting in the DMZ, so you need to secure them. In this blog post series I’d like to give a high level overview about the de facto standard for authorization – OAuth 2.0 and the emerging standard for federated authentication – OpenID Connect.
Authentication & Authorization
First, let’s define what authentication and authorization mean:
Authentication is the process in which we validate that someone is who they claim to be. Usually you can authenticate by providing at least one of the following factors:
- something you know – a password or a pin
- something you have – a certificate or an RSA token
- something you are – finger print
Authorization is the process through which we check the permissions that someone has. Although this can be modeled in multiple ways, it can be viewed as a matrix with subjects per lines, resources per columns and actions in cells.
OAuth 2.0
If we’re talking about API authorization, we need to also discuss about the delegated access model. The end user delegates access to his resources hosted on the web API to the client – the website. If we don’t want to pass the user’s credentials to the client and the APIs, then OAuth is a good choice. OAuth is an authorization protocol that can be used to enable limited access to private resources for 3rd party apps.
Continue Reading