Passwords: Identity’s last mile

At last week’s fourth annual Cloud Identity Summit (founded and curated by Ping Identity) people were still buzzing about the hornets’ nest we had stirred up a year earlier at the third summit when we baldly proclaimed “SAML is dead”.

SAML, the Security Assertion Markup Language, is part and parcel of the Ping Identity federation products. For the last twelve months I’ve been inundated with examples (many from Ping employees) of how SAML is still being implemented today.

Of course, as I noted at the time, the presentation was called “The Future of Authentication” and the context of the bald statement was: “SAML is dead does not mean SAML is bad. SAML is dead does not mean SAML isn’t useful. SAML is dead means SAML is not the future.”

So in that context it was very interesting to hear what Ping Chief Technology Officer Patrick Harding had to say in his keynote to this year’s Summit. He told his audience that what is needed is “a modernized identity protocol stack that is baked into every application that scales to Internet proportions, and hides its complexity from developers and end-users.” He went on to say that the foundation for this “identity stack” is shaped by a trio of emerging protocols -- OAuth, OpenID Connect (OIDC) and the System for Cross-Domain Identity Management (SCIM).

You’ll note the decided absence of SAML.

In fact, in the session a year ago we essentially said the same thing: OpenID Connect and OAuth 2 were the foundation for the future of authentication and authorization.

Harding also emphasized that in the coming API economy (another favorite of the analysts at KuppingerCole) it would not be about identity-enabled APIs with access tokens in their requests, but specific APIs for identity.  The key, according to Patrick, is simplifying everything as much as possible. "It is automation for developers, for end-users, we have to eliminate all the friction here," he said. "Developers should not have to know how OIDC and SCIM work." Instead, they should simply call an API just as they do for other services within their applications.

As we stated when we awarded the OpenID Foundation a 2012 European Identity Award:

“OpenID Connect is a simple JSON/REST-based interoperable identity protocol built on top of the OAuth 2.0 family of specifications. Its design philosophy is ‘make simple things simple and make complicated things possible’.

While OAuth 2.0 is a generic access authorization delegation protocol, thus enabling the transfer of arbitrary data, it does not define ways to authenticate users or communicate information about them. OpenID Connect provides a secure, flexible, and interoperable identity layer on top of OAuth 2.0 so that digital identities can be easily used across sites and applications.”

While it’s true that wider implementation of the “identity layer” Harding outlined in his talk would be greatly beneficial to users by vastly reducing the number of login ceremonies they’d be presented with (and, quite likely, the number of passwords to remember) there is an unspoken problem – the “elephant in the room” as it were. That is that the user must, at some point, authenticate to the Identity Provider!

Today, that means logging in to Google or Facebook or other IdP by providing, you guessed it, an account name and a password. Some IdPs (like Google) have provided for the ability to use two factor authentication (2FA) but it is optional and – from a security perspective – not much safer than a password alone.

The communications industries speak of “the last mile” (or last kilometer) as the most difficult part of their infrastructure – the connection from the backbone network to the individual subscriber. It is, typically, the slowest, most difficult – and most expensive on a per user basis – part of the network. That login to the IdP is the “last mile” for the identity stack that Mr. Harding (and Craig Burton before him) was talking about as our necessary future.

What we need, really, is an adaptive, dynamic, risk-based authentication and authorization system, based on context derived via open APIs, to correctly and properly authenticate those seeking access and determine the proper level of authorization for them.

If you are at all interested in this, you’ll want to join me for two upcoming webinars.

Next week, I’ll be discussing in greater depth “the Future of Authentication and Authorization,” and expanding on the thoughts I’ve laid out here. Then, in September, we’ll go into detail about how to bring about that future when I present “Authorization as a Calculated Risk.” (link to follow).

The authentication train is leaving the station, headed to the future. You really want to be on board.