2016 is drawing to an end, the goose is getting fat, the lights and decorations are adorning many a fire place and other such cold weather cliches. However, the attention must turn back to identity management and what the future may or may not hold.
Digital identity or consumer based identity and access management (CIAM) has taken a few big steps forward in the last 2 years. Numerous industry analysts, aka Gartner, Forrester and Kuppinger Cole, have carved out CIAM as a new sub topic of IAM, that requires its own market and vendor analysis. I think this is a valuable process, as CIAM projects tend to have very different requirements and implementation steps to traditional internal or employee based IAM.
From a predictions perspective, I see the following top 5 topics becoming key components of any digital identity platform for the next 12-18 months.
1 – Device Pairing Becomes a Base Requirement for IoT
Everyone knows about IoT. It’s going to save the planet. Increase personalisation. Create loads of data and bring most CISO and network security managers to their knees. Other than that, “smart devices”, aka devices that can talk at least HTTP (hopefully HTTPS) will be much more powerful and useful, when tied and paired to a physical personal identity. The classic “pin and pair” style use case. Take for example a smart-TV or a healthcare wearable. By tying the device to an individual, the device can not only access cloud services and API’s on the owners behalf, but can then in turn receive information to make the user experience more personalised.
A simple way to achieve this is via a draft IETF standard that leverages the popular authorization protocol OAuth2. This allows the device to receive a scoped OAuth2 access token that can be used to represent the real person to other services. More importantly the token can be revoked just like any other OAuth2 access token when the the device is sold or lost.
2 – OAuth2 Token Protection Becomes Mainstream
So what does this mean? OAuth2 and OpenId Connect are the now defacto method for application owners to integrate 3rd party authorization, identity assertions and other authX style use cases.
OAuth2 generates an access_token and refresh_token pair that are used to gain access to profile data or API’s for example. OpenId Connect extends this concept slightly, by also issuing an id_token that can basically act like a SAML2 identity assertion.
However…the access tokens, are bearer tokens. What does that mean? Well if you are in possession of the token, you basically have access. Assuming the token is valid of course. This opens up the possibility that tokens can be stolen (thinking insecure communications channels, MITM, man-in-the-middle) and then reused maliciously. The resource servers, by design only really check that the access token is valid and has the correct scopes/permissions – they don’t check that the person, application or device that is presenting the token is the correct owner of the token. Bad times.
Another draft IETF standard focuses on generating tokens that basically can’t be reused if stolen. Each issued token contains a little piece of the requester – aka their public key. This allows the resource server to extract the public key from the access token and generate a challenge response dance with the requester, to see if they are in fact the correct holder of the corresponding private key pair. If they are, great, access granted. If not, well access is not granted as they are not the original token owner.
3 – Social Signup Default
Social signup and sign in (aka Sign in with Facebook..) is so omnipresent in the applications and consumer services world, that enterprise service providers, be it in the public sector deliverying government services or the private sector deliverying banking, insurance or retail services, can not ignore the end user benefits it can bring.
Not only does it speed it the user registration process, it also reduces the over head for the service provider, in that they no longer need to handle password storage. The user is authenticating with a 3rd party, so it allows the service provider to out source the password storage to Google, Facebook, Microsoft or whomever.
The flip side of using a 3rd party, is that you have to trust their vetting, registration and data storage capabilities. Social networks are notorious for the having fake accounts, or accounts that no longer map into the correct owner. If you are a service provider leveraging social sign in, your applications and data assurance standards need to align and add extra levels of assurance or verification as necessary.
4 – Push Authentication Default
What is push authentication? I thought one-time-passwords (OTP) were going to save the world? Well OTP’s are certainly not going away any time soon, but many consumer facing sites and indeed social networks, are now introducing push authentication. This basically occurs via a mobile app that creates notifications during login time. The device and app and previously registered to the user. During login time, the end user performs a simple action (generally a finger-print scan or a swipe) to confirm they are the user logging in. Push is certainly becoming the standard mechanism amongst the under 30’s and no doubt will replace OTP for enterprise multi-factor-authentication soon.
5 – Stateless Tokens & Micro-services a Match Made in Heaven
Microservice architectures seem to be everywhere. Out with monolithic apps that often have long delivery cycles and lots of fragility and in with tiny, often single function applications, that are loosely coupled, that can be delivered and updated continuously.
However, that then introduces new challenges and requirements surrounding authentication and authorization in a microservices world. Here, OAuth2 again tends to come to the rescue, as many microservice or single function systems, are generally just exposed API’s, sitting behind a routing and throttling mechanism. Add in to that mix the ability to have stateless access tokens (that is, an access token that is a JSON Web Token, that carries all of the access, validity and permissions data with it in one place) and you can start to support multi-million transaction style infrastructures.
Microservice infrastructures tend to get hit hard. Very hard. Multi-million requests per day, performing GET’s to retrieve data, or POST’s to update, with each transaction perhaps hitting 10, 20 or 100 tiny independent services. By being to pass down an access token within an HTTP authorization header is powerful and flexible and couple with that a token that is stateless provides the necessary scaling back bone.
But why is stateless so interesting here? A stateless access token allows local introspection before access is given. That allows a microservice API to verify and look inside the presented JWT (which will appear in the Authorization header) without making a call back to the authorization service that issued the token. This reduction in hops can be pretty useful in high volume ecosystems – albeit the microservice will need the public key of the authorization service to verify the tokens and some extra code to verify and then introspect attributes like the exp, aud, scopes etc.
Interesting to see where we are come this time 2017…