On Fri, 27 Jul 2012 16:03:34 -0700, Rob Lanphier robla@wikimedia.org wrote:
On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp csteipp@wikimedia.org wrote:
I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store.... etc. But it would be good to hear from other developers if they have thoughts on it?
Separate user rows for OAuth?
OAuth 2.0 has a "scope" field to let the client request an auth token with the scope of the permissions it is requesting, which is a space delimited list of scope strings, to which the server can respond with an auth token that includes that scope list, a different scope list, or an error.[1]
I think creation of an OAuth token should result in the creation of a MediaWiki session, and that scope should be added to the session data. In our initial implementation, I think each of scope strings should correspond to MediaWiki permissions (i.e. mCoreRights in User.php). However, we should think ahead to the day when we might want to have something more fine grained than that.
Rob
[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3
No, I already know about scope. I was just confused what Chris was trying to describe when he grouped separate topics into one paragraph.
OAuth 2 scope can actually apply to the auth code, refresh token, and access token separately. The auth code's scope defines the refresh token's scope. And the refresh token's scope is used when defining the access token's scope. But it's possible to use a refresh token to request an auth code with less permissions than what the refresh token has.
I don't think 'session' will work in the context we currently use it in core. Authorizations, especially refresh tokens are persistent while session storage is ephemeral and can easily forget something we don't want it to forget. We also want to be careful about touching the session data at all. Besides the point that OAuth doesn't use cookies anywhere at all we want to be careful with the fact that we're probably going to need to support an OAuth + CORS environment where we want to erase all cookie and session data and pretend it doesn't exist even if the browser sends it.