On Fri, 27 Jul 2012 16:03:34 -0700, Rob Lanphier <robla(a)wikimedia.org>
wrote:
On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen
<lists(a)nadir-seen-fire.com>wrote;wrote:
On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp
<csteipp(a)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.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [