lists at nadir-seen-fire
Jul 27, 2012, 4:32 PM
Post #5 of 5
On Fri, 27 Jul 2012 16:03:34 -0700, Rob Lanphier <robla [at] wikimedia>
Re: OAuth, abstract implementation, and built-in unknown / internal / import applications.
[In reply to]
> On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen
> <lists [at] nadir-seen-fire>wrote:
>> On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp <csteipp [at] wikimedia>
>>> 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
> 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.
> 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.
> our initial implementation, I think each of scope strings should
> 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.
>  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
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.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Wikitech-l mailing list
Wikitech-l [at] lists