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-ssltl…
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-12