Authentication and Authorizing for WebService/REST API Calls

The purpose of this article is to be an overview of how the concerns of Authentication and SSO come together to plug into Authorization (mainly in the scope of API authorization). Application Architectures utilize industry standard protocols and patterns necessary to work together in all applications such as B2C, B2B, and B2E. The primary audience of this document is application architects and application security architects. However, those in the Identity and Access Management space will also find the concepts presented here apply to them.

Web Application and Mobile Thick Client Authentication Strategy

User Authentication and Authorization across web applications (both mobile and non-mobile) for all application realms (B2C, B2B, and B2E) should focus on SSO (Single-Sign-On). Web applications authenticate users using an Identity Provider that supports the standard like SAML2 and OAuth2. In addition, all mobile (Phone or Tablet) thick applications should authenticate their users by utilizing an Identity Provider that supports the industry standard OAuth2 Protocol. 

JWT: JSON Web Tokens

JSON Web Token (JWT) is a JavaScript object notation that is a representation format for HTTP HTTP Authorization headers and query parameters. JSON is used in REST API payload along with JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure for enabling the claims to be digital. JWTs are always represented using the JWS / JWE Compact Serialization. JWT works by simply encoding a string made up of a small JSON object and hashing it using a secret shared between the two parties. The algorithm is configurable but is usually HMAC SHA-256. JWT does not encrypt the payload, and it only signs it.

Web Application Authentication and SSO

The industry standard-based approaches for web application authentication and SSO center around two protocols.

• SAML 2.0
• OAuth2

OAuth2 protocol was initially widely adopted by large social sites (Facebook, Google, Twitter, etc.) for authentication as they have taken OAuth2 and created proprietary SSO mechanisms. As a result, users can go back and forth between their applications after being authenticated while using their APIs. While SAML 2.0 enjoys wide adoption in old applications for authenticating REST/JSON overtook SOAP/XML. Nowadays, all the applications are adopting OAuth2 as a standard.

OAuth 2 Access Tokens

RESTful APIs are secured using OAuth2. Expect an OAuth2 access token to be provided by the caller. The access token provided by the caller should only be passed as an Authorization HTTP Header such as:

• Authorization: Bearer access_token

Clients interact with RESTful APIs over HTTPS/SSL, and the contents of the HTTP Headers and thus the access token is encrypted. Therefore, passing OAuth2 access tokens via query parameters such as below is prohibited as standard because the access token, which must be kept secret, is exposed in transit and appears in web server logs. 

• https://<<URL>>/profile?access_token=MzJmNDc3M2VjMmQzN

So, the critical point is that the clients must obtain an OAuth2 access token for interacting with RESTful APIs. There are several ways to get tokens depending on the type of application, the authorization source involved, if an SSO approach is employed, etc. All of these approaches require communication with the OAuth2 Authorization Server. It is essential to understand that the OAuth2 framework does not provide SSO. 

Roles in OAuth2

• Resource Owner - This is the user using the application and owns/has rights to access the data provided by the resource server. They authorize a client application to access back-end data.
• Resource Server - The server where the RESTful APIs are exposed. 
• Client Application - The application requesting access to a resource server. It can be a traditional web application, a JavaScript (Single Page Application or SPA) application, or a mobile application.
• Authorization Server - The server issues an access token to the client. The client uses these tokens to request access to the resource server. 

OAuth2 REST API Access

The web application needs to access RESTful APIs, and the web application already possesses an access token delivered along with the JSON Web Token (JWT) when the user is authenticated. Since OAuth2 requires authentication to provide an access token, and the application already has the access token due to user authentication, the two come together using this pattern. This applies to all web applications where both are used and a user has already logged in. OAuth2 compliant authorization servers return a JWT with user claims at the OAuth 2.0 token validation endpoint. OAuth2 Connect compliant identity servers return a JWT containing the user claims. OAuth2 compliant authorization servers can return a JWT or JSON as the user info endpoint response.

It is always a good idea to expose to secured SSL and TLS channels for all REST APIs. Finally, OAuth2 is a widely used authentication of REST APIs in microservices architectures using JWT token mechanism.