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
