OAuth & Authentication / What can go wrong? Working Session of IETF - OAuth

Session Topic: OAuth and Authentication

Tuesday 3C

Convener: Hannes

Notes-taker: Hannes

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Justin presented the write-up about OAuth & Authentication that was sent to the IETF OAuth mailing list, see http://www.ietf.org/mail-archive/web/oauth/current/msg13708.html

The meeting lead to good feedback that will have to be incorporated and several persons volunteered to do another review.

Notes by Matt Berry

OAuth 2 is more of an auth framework than a complete auth stack. A result of that is that many RPs implement what they think is a secure OAuth stack, but what is in fact not secured. The reason is often due to one of a small number of common pitfalls that the OAuth Working Group is hoping to solidify in a blog post. One major point is that OAuth is not an authentication protocol. As Justin put it “it is the difference between chocolate and fudge. You need chocolate to make fudge, but one is not the other”.

A pre-publish copy of the blog post is available at Justin’s Github repo. Justin is appealing for copy editors before the post is sent to the website to be published. The key items on the “don’t do this list” are:

1. Using possession of an authorization token as proof of authentication (it’s not)

2. Using an OAuth protected identity endpoint as proof of authentication (it’s not)

3. Accepting access tokens from places other than the authorization server (don’t do this)

4. Accepting access tokens that lack audience restrictions (could be hijacked)

5. Spoofing of user info endpoint as a means of injecting user information (a la #2)

The point #4 is an interesting one because OAuth lacks a means to convey that information. Two options are to have a token identity endpoint where the audience is returned, another is to introduce a second token into OAuth (at this point, just use OIDC).