Standards Corner: OAuth WG Client Registration Problem

Update: Cross-Posted on the Oracle Fusion Middleware blog.

This afternoon, the OAuth Working Group will meet at IETF88 in Vancouver to discuss some important topics important to the maturation of OAuth. One of them is the OAuth client registration problem.

OAuth (RFC6749) was initially developed with a simple deployment model where there is only monopoly or singleton cloud instance of a web API (e.g. there is one Facebook, one Google, on LinkedIn, and so on). When the API publisher and API deployer are the same monolithic entity, it easy for developers to contact the provider and register their app to obtain a client_id and credential.

But what happens when the API is for an open source project where there may be 1000s of deployed copies of the API (e.g. such as wordpress).  In these cases, the authors of the API are not the people running the API. In these scenarios, how does the developer obtain a client_id?

An example of an "open deployed" API is OpenID Connect. Connect defines an OAuth protected resource API that can provide personal information about an authenticated user -- in effect creating a potentially common API for potential identity providers like Facebook, Google, Microsoft, Salesforce, or Oracle.  In Oracle's case, Fusion applications will soon have RESTful APIs that are deployed in many different ways in many different environments. How will developers write apps that can work against an openly deployed API with whom the developer can have no prior relationship?

At present, the OAuth Working Group has two proposals two consider:

Dynamic Registration

Dynamic Registration was originally developed for OpenID Connect and UMA. It defines a RESTful API in which a prospective client application with no client_id creates a new client registration record with a service provider and is issued a client_id and credential along with a registration token that can be used to update registration over time.

As proof of success, the OIDC community has done substantial implementation of this spec and feels committed to its use.  Why not approve?

Well, the answer is that some of us had some concerns, namely:

1. Recognizing instances of software - dynamic registration treats all clients as unique. It has no defined way to recognize that multiple copies of the same client are being registered other then assuming if the registration parameters are similar it might be the same client.
2. Versioning and Policy Approval of open APIs and clients - many service providers have to worry about change management. They expect to have approval cycles that approve versions of server and client software for use in their environment.  In some cases approval might be wide open, but in many cases, approval might be down to the specific class of software and version.
3. Registration updates - when does a client actually need to update its registration?  Shouldn't it be never?  Is there some characteristic of deployed code that would cause it to change?
4. Options lead to complexity - because each client is treated as unique, it becomes unclear how the clients and servers will agree on what credentials forms are acceptable and what OAuth features are allowed and disallowed.  Yet the reality is, developers will write their application to work in a limited number of ways. They can't implement all the permutations and combinations that potential service providers might choose.
5. Stateful registration - if the primary motivation for registration is to obtain a client_id and credential, why can't this be done in a stateless fashion using assertions?
6. Denial of service - With so much stateful registration and the need for multiple tokens to be issued, will this not lead to a denial of service attack / risk of resource depletion?  At the very least, because of the information gathered, it would difficult for service providers to clean up "failed" registrations and determine active from inactive or false clients.
7. There has yet to be much wide-scale "production" use of dynamic registration other than in small closed communities.

Client Association

A second proposal, Client Association, has been put forward by Tony Nadalin of Microsoft and myself. We took at look at existing use patterns to come up with a new proposal. At the Berlin meeting, we considered how WS-STS systems work.  More recently, I took a review of how mobile messaging clients work. I looked at how Apple, Google, and Microsoft each handle registration with APNS, GCM, and WNS, and a similar pattern emerges.  This pattern is to use an existing credential (mutual TLS auth), or client bearer assertion and swap for a device specific bearer assertion.

In the client association proposal, the developer's registration with the API publisher is handled by having the developer register with an API publisher (as opposed to the party deploying the API) and obtaining a software "statement". Or, if there is no "publisher" that can sign a statement, the developer may include their own self-asserted software statement.

A software statement is a special type of assertion that serves to lock application registration profile information in a signed assertion. The statement is included with the client application and can then be used by the client to swap for an instance specific client assertion as defined by section 4.2 of the OAuth Assertion draft and profiled in the Client Association draft. The software statement provides a way for service provider to recognize and configure policy to approve classes of software clients, and simplifies the actual registration to a simple assertion swap. Because the registration is an assertion swap, registration is no longer "stateful" - meaning the service provider does not need to store any information to support the client (unless it wants to).

Has this been implemented yet? Not directly. We've only delivered draft 00 as an alternate way of solving the problem using well-known patterns whose security characteristics and scale characteristics are well understood.

Dynamic Take II

At roughly the same time that Client Association and Software Statement were published, the authors of Dynamic Registration published a "split" version of the Dynamic Registration (draft-richer-oauth-dyn-reg-core and draft-richer-oauth-dyn-reg-management). While some of the concerns above are addressed, some differences remain. Registration is now a simple POST request. However it defines a new method for issuing client tokens where as Client Association uses RFC6749's existing extension point. The concern here is whether future client access token formats would be addressed properly.  Finally, Dyn-reg-core does not yet support software statements.

Conclusion

The WG has some interesting discussion to bring this back to a single set of specifications. Dynamic Registration has significant implementation, but Client Association could be a much improved way to simplify implementation of the overall OpenID Connect specification and improve adoption. In fairness, the existing editors have already come a long way. Yet there are those with significant investment in the current draft. There are many that have expressed they don't care. They just want a standard. There is lots of pressure on the working group to reach consensus quickly.

And that folks is how the sausage is made.

Note:  John Bradley and Justin Richer recently published draft-bradley-stateless-oauth-client-00 which on first look are getting closer. Some of the details seem less well defined, but the same could be said of client-assoc and software-statement. I hope we can merge these specs this week.

New Draft for Enabling OAuth2 To Be Used for Authentication

In my last blog post, I discussed the issue of OAuth2 and authentication:  Simple Authentication for OAuth 2? What is the Right Approach? As promised, I submitted a draft to the IETF for discussion in Berlin at the beginning of the month. While the working group didn't get a lot of time in the meeting to talk about the authentication issue (it wasn't formally on the charter), the submission did receive quite a bit of discussion in the hallways and on the IETF OAuth WG mailing list -- some of which I have already addressed in my last blog post.

Since the Berlin meeting, I have reviewed the feedback and have submitted an update. Draft 01 is now aligned to be compatible with OpenID Connect. In other words:

• If you are a web  developer, and the only problem you want to solve today is "how can I use OAuth to authenticate my users?", the new User Authentication and Consent for Clients draft is intended to solve just that problem. 
• But, if you decide you want to add an attribute provider (user profile) services to your requirements, you can upgrade to the OpenID Connect drafts as an extension to authentication without impacting existing code.

The new draft also allows clients to request a minimum Level of Assurance (per NIST-800-63 or ISO 29115) for the authentication -- a useful feature if the clients would like the service provider to do a higher assurance authentication (such as a multi-factor or biometric) than it might otherwise normally perform.

My thanks to Tony Nadalin and Mike Jones of Microsoft for their contributions to this draft.

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.

IIW XII: Adding Identity Information to OAuth2

IIW XII is coming up October 18-20, so I thought I'd share with you a couple of discussions I'd like to open at IIW. The first one is how best to add user identity or authentication information to OAuth2.

The OAuth Identity Information Problem
As many of you know, OAuth2 enables a process whereby a client application, as authorized by a user, is issued a "valet key" (a token) for accessing protected resources controlled by the same user at some resource site/service provider.

One limitation of OAuth "valet keys" is that client applications do not receive information about the authorizing user. From the client application's perspective, the authorizing person is anonymous unless the underlying resource API (e.g. a social graph API) can reveal information about the authorizing user. To date, this has been the typical technique used with Twitter and Facebook. But what if, instead of a social graph API, the resource being accessed by a client application is a bank account, a set of medical test results, or a set of photos? Obviously not all resource service providers provide identity information. What if there was a standard way for client applications to obtain information about the authorizing user?

OpenID Connect's Proposal
Members of the OpenID Foundation have already been working on this. OpenID Connect has been touted by many as an important addition to OAuth2 because it would define a way for an artifact to be passed to the client application that the client could use to obtain more information--or, so I thought. Instead, the current "connect" specification suggests that an ID_token be given directly to the client in addition to the resource access token that shares basic profile information. Is this sharing of information going to be acceptable to all OpenID Providers? Shouldn't there be a trust mechanism between client applications and identity providers (OPs)?

Further, the "Connect" specification seems to assume that only OpenID Providers would be used by a resource provider and its OAuth authorization server. What happens if resource providers want to use multiple types of authenticating services such as local authentication via LDAP or federation through SAML? It seems there is something missing with the current Connect proposal. We need a way for OAuth to hand off identity information while not mandating a single protocol solution. We need a way for multiple federation protocols to work at the same time in an OAuth based service.

While I liked the original idea of OpenID Connect, I think the hand-off between OAuth2 and identity sources needs to be more flexible.

Proposing an OAuth Identity Draft Discussion
A new IETF OAuth Identity draft that lays the foundation for resource sites to be able to share artifacts that enable clients to obtain identity and personal information seems to be needed. It would enable an open solution whereby resource sites could freely choose from the many types of identity providers out there. A core OAuth Identity specification could leave room for differentiated service approaches (e.g. session management) between OpenID, SAML or any other protocol, while defining the key inter-op/hand-off points with OAuth2. Based on such an IETF draft, individual protocol profiles could then lay out the details of how particular protocols such as OpenID, or SAML, or other APIs/protocols should work in relation to OAuth2.

Comments? Thoughts?

If you are going to IIW XII, I'll have a quick ppt with some thoughts on the issues to get the discussion going. Let me know if you are interested in contributing.

ps. Don't forget to register for IIW.

Time For Customers to Shout!

The attempt to merge various identity standards appears to be on the rocks with Johannes and Kaliya commenting here about the withdrawl by the Identity Commons folks.

Johannes is on the money about the culture clash. But in the end, the real loser is the customers as the the Identity version of HD-DVD vs Blu-Ray debate over competing standards and features will continue.

Customers, it is your time to shout! Contact your vendors (including my employer) and make yourselves heard! The vendors and open source communities need to hear from you!

InfoCards & OpenId - Authentication Is Still A Problem

Kim Cameron comments today on a New York Times article on OpenID and Information Cards.

In his blog post, Kim comments that if people just use InfoCards, than phishing attacks for passwords are no longer possible.

When people authenticate to OpenID in a reliable way - for example, by using Information Cards - the phishing attacks are no longer possible, as I explain in this video. At that point, it becomes a safe and convenient way to use a public personna.

Honestly, I don't see why InfoCards is any better with regards to passwords than is OpenID. Both systems allow a provider to issue "authentication" assertions that a web site (relying party) can use.

In Kim's video, he points out that by using his personal "IdentityBlog" I-Card to access the evil web site, no password is provided. If no password is involved, how can the evil web site gain anything useful?

It all sounds wonderful. But Kim skips over the problem of how did he get that card? How was he originally authenticated when the card was issued?

Is the information card periodically refreshed or re-authenticated? If it lasts forever, what happens if the information is lost or copied? What happens if someone else is using his workstation? What happens when the Kim switches workstations? For example, Kim decides to check his CNNPolitics profile from a friend's house? He'll likely have obtain a new card. I suspect that will involve some form of authentication with his managed card provider. It is clear, while InfoCards may reduce the need for authentication and passwords it does not eliminate them.

So if we assume that managed cards require authentication and re-authentication, then those ceremonies will be well placed in the user's experience. What is to stop an evil-doer from simply saying your managed card has expired, please re-authenticate? The ceremony is familiar, so will the user be alerted to something unusal? We are right back to where we started.

Now don't get me wrong. I'm a big fan of both OpenID and InfoCards. I'm just frustrated that one of the key pillars, authentication, is not sufficiently handled by either system.