Hi all,
I wanted to get some input from you all about any ideas or plans they have for identifying OAuth user in your applications. tl;dr, Since lots of people want to do authentication with OAuth, I'm thinking we'll implement a custom way to get identity information from the wiki in the near term, and then probably try to implement the OpenID Connect extension to OAuth 2 sometime next year. Since we started rolling out OAuth, we've consistently had requests to use OAuth to authenticate users in other applications, based on their wiki identity. OAuth does not support this, since the results of an api call using OAuth signatures aren't signed (only the request from the OAuth consumer is signed), so it's possible that an attacker could forge a response back to the application, and the application would think a different user was logged in. This is less likely if you're using https for your api calls, but it's surprisingly hard to get https right [1], even if you trust all your CA's. We were planning to roll out OpenID this fall to authenticate users, while OAuth is used for authorizing access into the wiki. Wikinaut has been working hard on the OpenID extension, but it's not quite ready to deploy yet. Additionally, with this setup, applications like Snuggle and UTRS that want to both authenticate users and use OAuth for authorized api requests have to implement both OpenID and OAuth libraries, which is a pain. This is a common issue is being addressed by the OpenID Connect extension to OAuth2, which allows the application to request information about the person doing the authorization, and the result is signed by the server to prevent tampering. The standard is still a draft, but it seems like the correct solution to our pain point, so I think that's the direction we'll head once the standard is finalized, and we have some time to throw at it. In the meantime, I'm also thinking we may implement something similar, where an OAuth consumer can request a signed assertion about the authorizing user. It would probably use the same format that OpenID Connect uses (JWT [2]), and use the consumer secret for the hmac signature. This would let the application check that a user has a specific set of permission at the time of the call, and would require a lot less development effort. Does this seem like a reasonable tradeoff? Assuming we do this direction, what attributes about the wiki user account should be provided. I was planning on username, if the account is autoconfirmed, maybe number of edits, and the list of groups to which the user belongs. Anything else? [1] - http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls... http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-12