Simple Authentication for OAuth 2? What is the Right Approach?

Over a year ago, several people, including myself, raised concerns about using OAuth (RFC6749) for authentication. By this I mean, that application developers are using OAuth enabled service providers as a way to authenticate their users (using Google, Facebook, LinkedIn, Twitter, or another major provider). They do this because they want to eliminate friction by forcing customers to create yet-another-user-id-and-password. John Bradley blogged about the problem, as did Vittorio Bertocci. Vittorio pointed out that authentication using OAuth is possible – it is just that authentication isn't formalized; authentication happens as a side-effect of authorizing a client to access a resource.

I agree with Vittorio, to fix this a simple specification is needed where by a service provider's authorization server shares with the client application (the one that wants to authenticate users), the user login information it knows about the user such as:

• Which user-id was authenticated?
• When did they login?
• How long is the login assertion good for?
• A possible (preferably directed) URI for User profile information?
• And, potentially to what assertion level were they authenticated? 

Many, including myself, suggested that the solution to the problem is to use OpenID Connect (OIDC).  OIDC solves the authentication standardization problem and further, it specifies a way to gain access to user profile information. In a sense, it turns an OAuth2 Service Provider into what we used to call an Identity Provider or IDP in many federation systems.

Despite these strong recommendations, I continue to see implementations and customer requests that require doing exactly what we warned was not standardized and not a good practice. Part of the complaint is that service providers have been slow to adopt except for a notable exceptions (namely Google). I also heard from last weeks CIS Nape conference that SFDC is planning to include OIDC in its platform.

I have asked many of the OIDF membership about this, and they claim there is a minimum profile. Yet, the "minimum" profile exists for the clients, not for the service providers. In a conversation only yesterday with Brian Campbell of PingIdentity (some tweets removed for clarity), we quickly got to the crux of the issue:

@leastprivilege @independentid @paulmadsen @vibronet there already is. You just have to find it in the mountain of specs.
— Brian Campbell (@__b_c) July 17, 2013

@leastprivilege @independentid @paulmadsen @vibronet response_type=id_token and scope=openid+whatever
— Brian Campbell (@__b_c) July 17, 2013

@__b_c @leastprivilege @paulmadsen @vibronet right but as can't implement just that flow.
— Phil Hunt (@independentid) July 17, 2013

@independentid @leastprivilege @paulmadsen @vibronet they could if ignore MTI, which will happen I'm sure
— Brian Campbell (@__b_c) July 17, 2013

Brian went on to point out some other important concerns, such as will another spec cause more confusion than it prevents. He is right.

So, while it is possible for OIDC to do authentication only, it wasn't intended for this purpose. Further, OIDC requires that the scope parameter which is intended to refer to the resource being requested, is compounded with an additional parameter "openid".

OIDC has many features, including discovery, that are incredibly useful.  Loosely speaking it turns OAuth2 Service Providers into the older federation Identity Provider model. It imagines an ecosystem of OIDC providers where profile information can be obtained in a standard way. Yet, many client developers aren't interested in user profile attributes – they just want to eliminate the need for users to create yet another user-id and password. They just want the login session information and the ability to force re-authentication.

From the service provider's (e.g. the social networks) perspective, there are also concerns. They know that client application developers are using OAuth2 to leverage their authentication services. Yet, their business priorities aren't such that the service providers want to consider becoming a standard compliant provider of user profile information. What service providers would like is a way to support standardized authentication, without standardizing their own RESTful profile APIs or adding another API. Implementing the OIDC Profile API may be in their future, but they aren't ready to commit today.

One of the problems we have in the standards industry is we tend to want mark the number of "implementations" as a sign of success. We tend to ignore those who are not implementing or are not putting implementations into production. These silent participants often do not voice their concerns.

It's with these concerns, that I am writing a proposal to respond to the authenticate only need. The plan is to make it short and easy to implement. I plan to submit it when the next IETF submission window opens on July 29. Yet I hesitate to submit it. Should it go to the IETF?  After, all, that is where the security concern lies. Or is it something the OIDC designers should look at?  I'd like to open some discussion on this. What should be done about supporting authentication directly within OAuth2 as described above? Where should that work be take place?

If anyone is interested, please make a comment or send me an email. I'd like to get your input, concerns, and support.