Top 5 Digital Identity Predictions for 2017

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...

Top 5 Digital Identity Predictions for 2017

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 […]

Protect Bearer Tokens Using Proof of Possession

Bearer tokens are the cash of the digital world.  They need to be protected.  Whoever gets hold of them, can well, basically use them as if they were you. Pretty much the same as cash.  The shop owner only really checks the cash is real, they don’t check that the £5 note you produced from your wallet is actually your £5 note.

This has been an age old issue in web access management technologies, both for stateless and stateful token types, OAuth2 access and refresh tokens, as well as OpenID Connect id tokens.

In the hyper connected Consumer Identity & Access Management (CIAM) and Internet (Identity) of Things worlds, this can become a big problem.

Token misuse, perhaps via MITM (man in the middle) attacks, or even resource server misconfiguration, could result in considerable data compromise.

However, there are some newer standards that look to add some binding ability to the tokens – that is, glue them to a particular user or device based on some simple crypto.

The unstable nightly source and build of OpenAM has added the proof of possession capability to the OAuth2 provider service. (Perhaps the first vendor to do so? Email me if you see other implementations..).

The idea is, that the client makes a normal request for an access_token from the authorization service (AS), but also adds another parameter in the request, that contains some crypto the client has access to – basically a public key of an asymmetric key pair.

This key, which could be ephemeral for that request, is then baked into the access_token.  If the access_token is a JWT, the JWT contains this public key and the JWT is then signed by the authorization service.  If using a stateful access_token, the AS token introspection endpoint can relay the public key back to the resource server at look up time.

This basically gives the RS an option to then issue a challenge response style interaction with the client to see if they are in possession of the private key pair – thus proving they are the correct recipient of the originally issued access_token!

 

The basic flow, sees the addition of a new parameter to the access_token request to the OpenAM authorization service, under the name of “cnf_key”.  This is a confirmation key, that the client is in possession of.  In this example, it would be a base64 encoded JSON Web Key representation of a public key.

So for example, a POST request to the endpoint ../openam/oauth2/access_token, would now take the parameters grant_type, scope and also cnf_key, with an authorization header containing the OAuth2 client id and secret as normal.  A cnf_key could look something like this:

eyJqd2siOnsKICAiYWxnIjogIlJTMjU2IiwKICAiZSI6ICJBUUFCIiwKICAibiI6ICJ2TDM0UXh5bXdId1dEOVpWTDljaU42Yk5ybk91NTI0cjdZMzRvUlJXRkpjWjc3S1dXaHB1Si1iSlZXVVNUd3ZKTGdWTWlDZmFxSTZEWnIwNWQ2VGdONTNfMklVWmtHLXgzNnBFbDZZRWs1d1ZnX1ExelFkeEZHZkRoeFBWajJ3TWNNcjFyR0h1UUFEeC1qV2JHeGRHLTJXMXFsVEdQT253SklqYk9wVm1RYUJjNHhSYndqenNsdG1tcndzMmZNTUtNTDVqbnFwR2RoeWRfdXlFTU0wdHpNTGFNSVN2M2lmeFM2UUw3c2tpZTZ5ajJxamxUTUd3QjA4S29ZUEQ2QlVPaXd6QWxkUmJfM3k4bVA2TXY5cDdvQXBheTZCb25pWU8yaVJySzMxUlRaLVlWUHRleTllSWZ1d0ZFc0RqVzNES0JBS21rMlhGY0NkTHEyU1djVWFOc1EiLAogICJrdHkiOiAiUlNBIiwKICAidXNlIjogInNpZyIsCiAgImtpZCI6ICJzbW9mZi1rZXkiCn19Cg==

Running that through base64 -d on bash, or via an online base64 decoder, shows something like the following: (NB this JWK was created using an online tool for simple testing)

{
   "jwk":
            "alg": "RS256",
             "e": "AQAB",
             "n": "vL34QxymwHwWD9ZVL9ciN6bNrnOu524r7Y34oRRWFJcZ77KWWhpuJ-                               bJVWUSTwvJLgVMiCfaqI6DZr05d6TgN53_2IUZkG-                                                x36pEl6YEk5wVg_Q1zQdxFGfDhxPVj2wMcMr1rGHuQADx-jWbGxdG-2W1qlTGPOnwJIjbOpVmQaBc4xRbwjzsltmmrws2fMMKML5jnqpGdhyd_uyEMM0tzMLaMISv3ifxS6QL7skie6yj2qjlTMGwB08KoYPD6BUOiwzAldRb_3y8mP6Mv9p7oApay6BoniYO2iRrK31RTZ-YVPtey9eIfuwFEsDjW3DKBAKmk2XFcCdLq2SWcUaNsQ",
          "kty": "RSA",
           "use": "sig",
            "kid": "smoff-key"
     }
}

The authorization service, should then return the normal access_token payload.  If using stateless OAuth2 access_tokens, the access_token will contain the new embedded cnf_key attribute, containing the originally submitted public key.  The resource server, can then leverage the public key to perform some out of band challenge response questions of the client, when the client comes to present the access_token later.

If using the more traditional stateful access_tokens, the RS can call the ../oauth2/introspect endpoint to find the public key.

The powerful use case is to validate the the client submitting the access_token, is in fact the same as the original recipient, when the access_token was issued.  This can help reduce MITM and other basic token misuse scenarios.

This blog post was first published @ http://www.theidentitycookbook.com/, included here with permission from the author.