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.))