Google and OAuth 2.0 Compatibility (Eliminate all other factors, and the one which remains must be the truth. (Sherlock Holmes))

Over the weekend I was pinged by my QA engineers about new failures in our OAuth 2.0 test suite. Not a good sign, just a few days before the OpenIG 3.1 release date ! Anyway, I've made my hands dirty to track down the problem up to the source. Here is the story :)

This issue has been fixed the 12th of December 2014 (see stack overflow answer).

Everything starts with ...

... a failure, at least I had the screenshot of a nice Exception, pretty explicit by the way:

The failure

... then you start digging

... on your side. Yeah, you must have done something wrong in your code, Google is just working (Apple ©), right ?

The part of the code referred by that stack trace is dealing with the Access Token Response JSON structure returned from the OAuth 2.0 Token endpoint. But this has not been changed since it was first checked in (or almost, nothing recent at least), and the QA tests that were failing on friday have been working previously.

I've tried to think about every code checkin' to see the potential impact on the expected behaviour, found nothing.

On the QA side, they re-run an older OpenIG's version (that was working, remember ?), and now it's failing too !?


... looking more closely to what Google send

At that point, it's time to open your IDE and debug OpenIG, this way we'll see what see OpenIG see...

No wonder, it's really receiving a successful access token response of the following form:

  "access_token": "ya29.1gD56tBWtHW3K7oZ0FINTnsqa4VYiE2YGZeQXgJ4ID79E-mZxNWoyYi7pKrs_Vyxj8FZbuxh_RGTJw",
  "token_type": "Bearer",
  "expires_in": "3600",
  "refresh_token": "1/dGjGYC7sDFaBwpdUVpkJP2mYFYTU8HAh7T6szsKGYTs"

expires_in is really a String, even if semantically it's a Number !

Ok Google is now sending a String instead of a Number for this attribute.

My world collapse: Google can't be wrong for something that simple !

That reminds me a famous Sherlock Holmes quote: Eliminate all other factors, and the one which remains must be the truth.


... what about the spec ?

As per the OAuth 2.0 Spec, a successful response looks like the following:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

They even give a syntax for expires_in attribute:

expires-in = 1*DIGIT

Pretty simple, though ?

... let's find a solution

Hopefully, it was not very hard to fix: I just made one of our class a little bit smarter (dealing especially with the String case).

Tested and committed, ready for the release :)

... wait a minute, what changed on Google's side ?

They seem to have updated their OAuth 2.0 service implementation.

Take a look at the OpenID Connect Discovery endpoint returned JSON:

  "issuer": "",
  "authorization_endpoint": "",
  "token_endpoint": "",
  "userinfo_endpoint": "",
  "revocation_endpoint": "",
  "jwks_uri": "",
  "response_types_supported": [
    "code", "token", "id_token",
    "code token", "code id_token", "token id_token", "code token id_token",
  "subject_types_supported": [ "public" ],
  "id_token_alg_values_supported": [ "RS256" ]

And, more closely to the token_endpoint value: it's using a v3 API. It's not even advertised on the Google API Explorer (yet ?).

Another hint that something changed was in the last edited timestamp at the bottom of the OpenIDConnect and OAuth2WebServer google developers pages:

Edited on Friday the 5th

Funny facts

I played with Google OAuth Playground this morning (BTW, it's pretty neat and usable, good stuff).

Surprisingly, when you choose the Google OAuth endpoints set, you'll see they're not using the v3 one yet: they're using

When manually re-configured to use the v3 API, you clearly see the String:

Configured with v3 endpoints


BYOID: An Identity Frontier?

[bee-oi]. [b-yoy]. [be-yo-eye]. [bee-oy-ed].  Whichever way you pronounce it, the concept of bringing your own identity to the party is becoming a popular one.  Just this week Amazon jumped on the identity provider bandwagon, by introducing it's 'Login With Amazon' API.  What's all the fuss?  Isn't that just the same as the likes of Twitter and Facebook, exposing their identity repositories so that 3rd party application and service developers can leverage their authentication framework without having to store usernames and passwords?

Well in a word yes.  With the continual threat of hacking and cracking of consumer and business user account repositories, why wouldn't you as a developer, simply take advantage of someone else storing the password details on your behalf?  No need to worry about whether to use encryption or hashing, which algorithm to use, how to handle password reset management and so on.  Simply perform a call out during authentication time, probably using your favourite language, using a simple web standard and a way you go.  Simples.

Why It's Cool To Be An Identity Provider

So why have all of these identity providers sprung up?  Well in essence they haven't.  The Security Assertion Markup Language (SAML) has been around for the best part of 12 years and in the last 8 or so, has been implemented at numerous federation related projects both in the education, public and private sectors.  SAML has the concept of an identity provider, but that has been expanded in recent years to be more consumer orientated.  With the rise of social networking sites that house millions of user records and newer protocols such as OAuth(1 and 2), the use and consumption of these vast repositories is simpler.  From a social platform perspective (Facebook) or from a  consumer outreach perspective (Amazon) it makes pretty good business sense to get more applications, services and in turn users, using the sites and services they manage.  If you make cricket bats, you want to help those who make the balls.  It's the same with being an identity provider.  The consumer has a familiar (and to an extend trusted) account they use to log in with.  It's signal sign on, without all the password hiding and syncing stuff.

If The Consumer's Happy The Orgs Are Happy Right?

Well, if you're an identity provider, I'd imagine you are pretty ecstatic.  You have had to manage the user's password and account details in the past anyway.  So in theory they should be only a marginal cost to expose that information via an API to your apps developers or associated service providers.  Consumers are content as they don't have to create multiple accounts or remember lots of passwords each time they sign up to a new service or application.  But what about the non-consumer side of things?  Perhaps these users are also employees using their newly found identity freedom to access services and applications that are being used for business purposes.  Perhaps CRM systems, hosting providers, calendars, software repositories, syncing apps and so on.  How can that be managed and controlled?

Business Evolution Now Revolves Around Identity Management

I wrote recently about how modern enterprises now face significant challenges, as they expand into new business partnerships, with complex supply lines and an ever evolving mobile and now identity aware workforce.  For many organizations, their continual evolution into new areas of revenue, especially within the business to consumer space, will rely heavily on being able to manage both internal employee access to cloud based services, as well as managing their own consumers' access to their own resources.  Both can be complex, requiring unprecedented scalability and web enablement.

The 'consumer is king', now really translates to 'identity is king'.

By Simon Moffatt

Forget Firewalls, Identity Is The Perimeter

"It is pointless having a bullet proof double-locked front door, if you have no glass in your windows".  I'm not sure who actually said that (if anyone..), but the analogy is pretty accurate.  Many organisations have relied heavily in the past, on perimeter based security.  That could be the network perimeter or the individual PC or server perimeter.  As long as the private network was segregated from the public via a firewall, the information security manager's job was done.  Roll on 15 years and things are somewhat more complex.

"Identity as the perimeter" has been discussed a few times over the last year or so and I'm not claiming it as a strap line - albeit it is a good one at that.  But why is it suddenly becoming more important?

The Extended Enterprise - Mobile, BYOD, Consumer

Organizations of all sizes are no longer central places of work, with siloed business units, headed up by managers in glass-walled offices.  Remote working is no longer limited to cool startups or the creative industries.  Desktop PC's are now in decline, with tablets and smartphones able to do the majority of work related use cases.  Many organisations now have complex supply chains, leveraging partners, sub-partners, clients and consumers.  Outsourced services and applications now make up a large percentage of an organization's delivery management process, with these services often allowing authentication and user management controls outside of the standard corporate LDAP.

The increased use of BYOD, mobile workforces and increased outsourced and consumer lead service interaction, requires a much more integrated and agile view of an identity, but also requires CISO's, to view data protection and segregation in a much more user centric approach.

There Is No Network Separation - Everything is Connected

Everything is connected.  You can receive corporate email on your smartphone over a network carrier paid for privately.  Remote backup and file sync solutions allow sensitive files to be stored off site without the knowledge of a DLP solution.  There is no longer a 'corporate' network with strong demarcation lines.  Whilst this has obvious user benefits and efficiency gains, it has opened up new areas for security management.  The one thing which is staying relatively static is the that of the identity driving this change.  I don't mean the role and concept of identity is static.  Quite the opposite, but identities are still the driving force between application interactions, network traffic analysis, DLP techniques, firewall management and so on.  Each transaction should be linked in some way to an identity.  This identity could be well masked through alias upon alias, but there are fewer and fewer chances for a truly anonymous computer interaction.

Extend the Enterprise or the Stretch The Cloud?

These identities are developing in multiple directions.  The traditional corporate view of an identity originating from an authoritative source such as HR and flowing via provisioning systems to a target directory or database is still present.  Complex workflows and RBAC projects will keep many a consultant in work for years to come.  But with the onset of the extended enterprise, the increased use of social and cloud based identity brokers and platforms (Google, Facebook et al), there is a need for fusion.  The ability for organisations to extend to the 'cloud' and the for the internet based services and brokers to able to reach out to traditionally standalone organizations with their new apps and services securely, whilst still making the user experience convenient.  But where to start?  Traditional enterprise identity and access management solutions are often too static and unable to scale to internet style proportions.  Internet focused identity has been about single sign on, federation and authentication via social platforms. Organizations need to be able to manage interactions with 3rd party service providers from a centralised, potentially policy driven, authentication and authorization perspective.  It's pointless disabling a contractor's internal LDAP account if they still have an active Saleforce or Dropbox account when they've left.

Compliance doesn't just fade away in cloud and internet based scenarios.  There are still stringent controls that need to be adhered to, in order for an organization's identity management platform to be both convenient and effective.

By Simon Moffatt