Design patterns covered by this post have been used in Open Loyalty rewarding and CRM platform. Please check it on the github: https://github.com/DivanteLtd/open-loyalty.
Check the code!
Authorization is a key feature of any enterprise grade application. If you remember the beginnings of web 2.0 and Web API’s back then – typical authorization scenario was based on API key or HTTP authorization. With ease of use there were some downsides attached. Basically, these “static” (API key) and not strongly encrypted (basic auth.) methods were secure enough.
Here, delegated authorization methods come into action. By delegated, we mean that authorization can be given by an external system / identity provider. One of the first methods of providing such authentication was the OpenID standard developed around 2005. It might provide a One Login and Single Sign On for any user. Unfortunately, it wasn’t widely accepted by identification providers like Google, Facebook or e-mail providers.
The OAuth standard works pretty similarly to OpenID. The authorization provider allows Application Developers to register their own applications with the required data-scope to be obtained in the name of the user. User – authorizes specific applications to use with their account.
Facebook or Google Account login screens are a well-known part of OAuth authorization.
Authorization screen for Google Accounts to authorize external application to use Google APIs in the name of the user.
After accepting the application request the authority party returns a temporary Access Token which should be used with API calls to verify the user identity. The Internal Authorization server checks tokens with its own database of issued tokens – paired with user identities, ACLs etc.
Authorization tokens are issued for a specific amount of time and should be invalidated after it. Token authorization is 100% stateless; you don’t have to use sessions (like with old-good session based authorization). Oauth 2.0 requires SSL communication and avoids additional request-response signatures required by the previous version (request were signed using HMAC algorithms); also workflow was simplified with 2.0 removing one additional HTTP request.
Authorization flow for oauth2.
OAuth tokens don’t push you to display the authentication dialog each time a user requires access to their data. Following this path wouldn’t be possible to check e-mail in the background or do any batch processing operations. So how to deal with such background-operations? You should use “offline” tokens – which are given for longer time periods and can also be used to remember client credentials without requiring login/password each time the user hits your application.
There is usually no need for writing your own OAuth code as many open source libraries are available for most OAuth providers and frameworks. Just take a look on github!
There are SaaS solutions for identity and authorization such as Amazon Cogito or Auth0 that can be easily used to outsource the authorization of your API’s.
JSON Web Tokens (JWT)
Yet another approach to token based authorization are JWT (JSON Web Tokens). They can be used for stateless claim exchange between parties. As oauth tokens require validation by the authenticating party between all requests – JSON Web Tokens are designed to self-contain all information required and can be used without touching the database or any other data source.
JWT are self-contained which means that tokens contain all information. They are encoded and signed up using HMAC.
This allows you to fully rely on data APIs that are stateless and even make requests to downstream services. It doesn’t matter which domains are serving your APIs, so Cross-Origin Resource Sharing (CORS) won’t be an issue as it doesn’t use cookies.
EXAMPLE: We’ve used angular-jwt on the client side of Open Loyalty to authorize all the frontend operations. JWT are self-contained which mean you can decode all required data on the client side without breaching security.
Validation of HMAC tokens requires the knowledge of the secret key used to generate the token. Typically the receiving service (your API) will need to contact the authentication server as that server is where the secret is being kept.
Please take a look at the example.
Example token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwib mFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RM HrHDcEfxjoYZgeFONFh7HgQ
Contains following information:
| Header (algorithm and token type) | { “alg”: “HS256”, “typ”: “JWT” } |
| Payload (data) | { “sub”: “1234567890”, “name”: “John Doe”, “admin”: true } |
| Signature | HMACSHA256( base64UrlEncode(header) + “.” + base64UrlEncode(payload),) secret base64 encoded |
JWT tokens are usually passed by HTTP Bearer header, then stored client side using localStorage or any other resource. Tokens can be invalidated at that time (exp claim included into token).
Once returned from authorization, service tokens can be passed to all API calls and validated server side. Because the HMAC based signing process tokens are safe.
JWT based authorization is pretty straight forward and it’s safe. Tokens can be trusted authorized parties because of the HMAC signature; therefore information contained by them can be used without checking ACL’s and any further permissions.
Published May 8, 2017
