In the OAuth user stories it was suggested that we might want to support
OAuth "Implicit Grant".
-- Explanation of "Implicit Grant" --
In OAuth 2 the "Implicit Grant" is one where you send the user to the
Authorization endpoint. The user allows your application access. And then
sends the user back to the client with the Access token directly inside
the #fragment of the page. Instead of sending the user back with an
Authorization code in the query that lets the client request an Access
token.
This grant flow is useful for pure-JS applications with no server
component. For example browser extensions and more importantly
pure-JavaScript applications that don't want to interact with the server
they're on at all. eg: They may be served 100% statically with no
scripting on the server end. And they may support offline mode so the
server the application sits on doesn't even need to be online, while
thousands of people can be using the app.
((And I have a feeling this is the flow that all B2G based mobile phone
applications will end up using))
-- /Explanation --
My thought on this topic here is that for such applications in addition to
OAuth we're also going to have to consider implementing CORS in MediaWiki.
-- Rationale; Skip for TL;DR --
pure-JS applications naturally will want to use XHR for making API
requests. However the sameorigin policy will prevent them from accessing
the api.
Technically JSONP exists. But OAuth access tokens going over <script>s is
a horrid idea. You can't use 'mac' type access tokens over JSONP. JSONP is
insecure. And most importantly JSONP can't do POST. Which means that an
OAuth client using JSONP can't use the write api, which is practically the
whole reason for using OAuth.
Using a server to forward requests is completely unnecessary and adds a
hardware burden on the developer that does not need to exist. It also
makes the implicit grant pointless since you could just use the
Authorization Code Grant from the server.
-- /Rationale --
So naturally this means that along with OAuth we're going to have to
support CORS.
I have some ideas on how we should deal with CORS support:
- We'll always permit CORS requests, even without an OAuth authorization.
- Just like with JSONP all CORS requests lose session data and become
anonymous requests. (TBH, the best way to implement this would probably
actually involve unset() on all $_COOKIE and $_SESSION data so extensions
can't accidentally expose sensitive data)
- With the exception that a CORS request can contain an OAuth access token
and act as a user (potentially a different user than the one logged in at
that)
- CORS requests will be restricted to the API. Since there are some parts
of the site that could be problematic when accessed by the
- CORS requests will not have access to the write api. (ie: It will be
disabled without OAuth + an edit, etc... rights grant) This is different
than normal XHR requests to prevent random websites from being able to
make anonymous edits simply by having some random victim browse to their
website.
This will allow CORS + OAuth "Implicit Grant" to be used by client based
web applications. It will also allow a client based web application to
safely make a meta=siteinfo request before going in for an OAuth
authorization. Actually it'll just plain make it possible to ditch JSONP
for everything we were using it for before. Something I think we DO want
to encourage because of the security implications that JSONP has.
The only issue a client application may have right now with that CORS
setup might be discovery. We don't allow CORS requests for random pages on
the wiki. So the client won't be able to let the user input the url of a
random wiki and have the client do a RSD discovery on the wiki to find the
API url and start the oauth flow.
I suppose we could write a 3rd party service that'll do discovery and
allow random client-side web applications do discovery of random MediaWiki
installations.
((By the way. When we implement CORS I want an early peak at it. I can
already think of one security hole a mistake in the implementation could
open up))
((Actually I just came up with a second one right now. We need to make
sure that the edit tokens for OAuth requests are different than the actual
edit tokens. Otherwise they could be abused to trick the user's browser
into making an edit with the full authority of the user bypassing OAuth
restrictions.))
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
