Talk:OAuth

What's the reasoning of the Suggested Granularity of Permissions ?

The usergroup required to grant that right over oauth would be the same as for doing it through the interface (ie. to check if you have such right). If it's for a simplified userright selector, just show the groups available in the wiki.

That response on OAuth 2 over https is misleading. OAuth 1 included reasonable levels of security even without https, OAuth 2 removed them because they thought the signatures were too complex (And as far as discoverability the OAuth 2 editor has some negative comments about signature removal).

If this is going to be a real MediaWiki feature rather than something practically Wikipedia only then what we're really going to have to aim for is an abstract interface which is extended by extensions implementing OAuth 2, OAuth 1, and perhaps some other form of auth not something written from the start to only support OAuth 2.

AFAIK, signatures are back since OAuth 2 draft 11, and we are know at draft 22.

I read back through OAuth 1, OAuth 2, and the OAuth 2 MAC token specs. Taking a look at it I've found that while signatures are back in a way. From a security standpoint they are completely inferior to the signatures used inside OAuth 1. They only protect the resource server (and don't even protect that entirely) and don't protect the authorization server. In effect while OAuth 2 has "signatures", they are practically useless. You still need to run HTTPS on your wiki to be able to use OAuth 2 securely.

On this topic I ran into this post: http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/

It's nice to hear that signatures are coming back (though I can't find them when scanning the spec). But I do have something important on this topic:

• The big issue with not having signatures is discoverability. No signatures + discoverability = phishing basically.
• While everyone talks about OAuth on Wikipedia, the frank reality is what we'll be developing is OAuth for MediaWiki. Which is a different beast that will inevitably end with lots of small MediaWiki installations installing OAuth.
• We're also already talking about anti-vandalism tools using OAuth. And quite frankly, while Huggle is WMF-centric OAuth is inevitably going to be used for other anti-spam tools, bots, etc... which of course may not be WMF-centric.
• This means that discoverability is inevitable. We will have OAuth on many MediaWiki installations and we will have clients that want to work with more than just WMF.
• This also means that wikis without HTTPS are inevitable. There are thousands of MediaWiki installations without it, plenty that will have users that want to use apps that will use OAuth, and plenty without a budget for a SSL certificate.

So under these circumstances I think we need the following:

• When we do implement OAuth, we include the signatures implementation right away.
• By default we DO NOT support OAuth without signatures. Only wikis that have explicitly enabled non-signature support will accept clients not using signatures.
• Even when signatureless OAuth is enabled we ALWAYS support signatures. If a client asks for authentication using signatures we ALWAYS respect that.
• We keep the situation where we have an arbitrary number of MW API clients using OAuth and an arbitrary number of MediaWiki instances supporting OAuth in mind and remember we'll eventually need to support the situation where a client can work with a MediaWiki installation without the author explicitly registering with every MediaWiki instance in existence to support them all.

I know that there's still some issue with OAuth over http even with signatures. But I believe that's something that can potentially be handled in the discoverability process. It's also still better than the alternative.

I started brainstorming some of my own thoughts at User:Dantman/OAuth/Brainstorm.

Looking at the "Proposed database model" I see an "Access Range Table" with oar_key and oar_description.

• The real name is not "Access Range" but "Scope".
• And there is no way we're storing the description of a scope in the database when we already have an i18n system for that.

Considering these points it's becoming clear that the proposed database setup was just blindly created without an understanding of OAuth or the requirements we have of an OAuth implementation. So if nobody minds I'm just going to delete that section of the page till someone actually starts brainstorming an actual OAuth implementation.

Reading this comment brings up a point: http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/#comment-11353

• Tools like Huggle are desktop apps.
• We intend to allow people to use these over OAuth.
• However there is absolutely no way to verify what app is making these requests. It's impossible to use a client secret which is necessary for that doe be done.
• We have to accept that we're going to allow the use of clients without the use of a shared secret to identify what application has gone rogue.
  • The only alternatives are A) Do not allow any desktop apps (Unacceptable) B) Require desktop apps to try to use a client secret they inevitably cannot keep secret (This will lead to the potential for malicious apps to reuse the anti-spam tools' client secrets leading to anti-spam tools being blocked and reverted when we try to stop a malicious app.)

Given these facts here's my conclusion:

• We have to allow clients to be dynamically registered / authorized to a single user client secret instead of always pre-registered with a client secret (otherwise we risk malicious and non-malicious apps being grouped under the same app id and ending up with a useless interface that blocks too much). However we can still let non-pre-registered apps give a name for visual purposes.
• We make sure the UI dealing with registered apps has visual indicators to indicate the difference between a named app that's been pre-registered and a dynamically registered app (specific to one user) wherever we display an apps name. This is necessary to avoid sysops mass-reverting and blocking everything that comes from an app named "Huggle" because a malicious app started ussing the name "Huggle" in all of it's unverified OAuth connections.
• We understand and accept that a single app gone rogue may be using different application ids (ie: each user that has authorized it has authorized it as a different app) and deal with this fact by making it easy for sysops to revert and block multiple apps at the same time instead of forcing them to deal with 100 app registrations separately because one app has been used by 100 different users creating 100 apps that don't use client secrets.

I should rephrase myself after reading the spec in full:

• All clients have a client identifier
• There are confidential (hosted on a server) and public (client side, applications, mobile apps, etc...) oauth client types
• confidential client types have a client_secret to verify themselves
• public clients cannot have a client_secret because it's impossible to give one to the application, give the application to the user, and expect that they cannot find some way to extract the secret from the application
• This means we can't guarantee something that comes from a public client actually comes from that public client
• And we can't reliably mass-revert a public client by it's client id

My idea on how to solve this is:

• Don't place any dependence on the client_identifier for a public client (in fact, consider not even allowing an admin to mass-revert based on client_identifier if the client is public)
• Make the difference between confidential and public visually apparent in the UI (so that editors learn to understand that if they suddenly see "Huggle" going rogue the client itself may not actually be rogue).
• Use client_identifier for mass reverts of confidential clients. But when the client is instead public skip client_identifier and allow the admin to see edits grouped by what individual authorization to the client made the change. Using this method we should allow admins to do mass reverts by selecting a number of authorizations for a public client and specifically reverting those en-masse.
• Use an intuitive UI for mass-rollbacks. When the admin inputs what criteria they want to use for doing a mass-rollback display a sample of what they are going to revert so they don't make a mistake.

Side note but I think we should permit multiple redirect_uris to be registered, and allow for wildcards.

I finally found the spec for signatures in OAuth 2:
https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01

In particular I love the part in the spec that says:

The primary design goal of this mechanism is to simplify and improve
HTTP authentication for services that are unwilling or unable to
employ TLS for every request.

The database model proposed based on oauth2app looks like it may not be taking into account parts of OAuth 2 we'll be needing like the implicit flow. Also I believe we should separate the database model for 'Applications / Clients' that users authorize and the actual specifics of those apps in the OAuth context. This way we can maintain revocation, sysop tools, etc... separately from the actual OAuth implementation. eg: In case we find a reason to implement some other method of authentication besides just OAuth 2.

We should probably ditch the idea of basing our models off of a potentially half-implemented library and leave the database model up to the implementor who is actually reading the spec and taking into consideration the flows we need and the abstraction we should be implementing.

Something important to keep in mind with permissions is that by default granting 'edit' should not carry the rights to edit the user's .js page.

With this consideration and other fine grained rights that may be missing from the api-oriented method the other idea of basing OAuth permissions based on our actual rights system is probably the better way to go about this.

There are some rights like the ability to edit a user's permissions which we'll want to create some dummy rights for so that we can deny them by default to OAuth.

However something else we do have to be careful of is how we display to the user the list of rights that the application asked them to authorize. If we don't display these in a combined, grouped, clean, and intuitive way we risk overloading the user with so much information that the user starts ignoring the list of rights and will grant permissions to apps which they shouldn't allow it to have.

Firstly we should probably add a $wg which we add information on what category rights are in based what area they effect. For example edit, createpage, and upload would be grouped together as rights that affect content on the page. While rights like protect and delete would be grouped together as rights that do administrative things on the wiki. And rights like 'watch' and 'permissions' would be grouped together as rights that affect the user's own account.

If we don't group things like that we risk sysops not noticing when an application randomly requests their delete right.

Secondly we should find some way to group multiple requested rights into a single line in the display. For example for [edit] we would display "Edit existing pages on the wiki" while for [edit, createpage, createtalk] we would display "Create and edit pages on the wiki". If we don't do it this way we'll end up outputting things like "Edit pages. / Create pages. / Create talkpages." and overloading the user with a huge pile of rights lines.

This page doesn't seam to reflect the OAuth plans that I've seen people discussing. Especially with that minimum MediaWiki bit. The plans I've seen people talk about necessitate that every change made by a 3rd party that's authenticated through something like OAuth be attributable to that app. ie: Every edit, log, etc... needs a field and code that associates an app. And there are many features expected to be generic rather than OAuth dependent (things like authorizing/blacklisting apps and listing authorizations), while the actual OAuth itself would be an extension. Under those plans, I don't see OAuth support working in anything but a new version of MediaWiki. Core would have the generic functionality baked into it and an extension would tie in actual OAuth implementation etc...

Hi Daniel,

I am curious to know where those discussions happened as I haven't been able to find them :) I would like to hear the use-case where we would want a 3rd party app make actions on behalf of it's user without the user explicitly taking the action self. In our proposal we assume that all actions are always taken by an individual and hence each action is always attributable to an individual.

Best,

Diederik

Drdee 00:25, 18 November 2011 (UTC)

Hi Daniel,

I am curious to know where those discussions happened as I haven't been able to find them :) I would like to hear the use-case where we would want a 3rd party app make actions on behalf of it's user without the user explicitly taking the action self. In our proposal we assume that all actions are always taken by an individual and hence each action is always attributable to an individual.

Best,

Diederik

Drdee 00:25, 18 November 2011 (UTC)

We don't want an app to make actions using a user's account that the user didn't want to be made. But it's 3rd party code, there's no way to guarantee that. So, every change gets associated with what app made it. So when an app goes rogue and starts abusing dozen's of users accounts to spread goatee images, we know precisely which app is responsible, and we can blacklist it and revoke it's permission to do anything with any user account.

Ok, I'll add that to the requirements & datamodel.

Daniel, that's correct – we definitely want to have the ability to revoke permanently and globally permissions for an app and to mass-revert or mass-redact any abusive edits produced by that app and the requirements should reflect this possibility. We'll need to figure out the legal and technical implications, as for the technical aspects the ability to tag specific revisions with a unique id associated with the key used by the app is an obvious requirement if we want to be able to mass-revert.

That wikitech-l discussion should cover a lot. One small relevant OAuth discussions in irc: http://toolserver.org/~mwbot/logs/%23mediawiki/20110816.txt

Hi Daniel,

You mentioned that "Every edit, log, etc... needs a field and code that associates an app." I am not sure if that is the way to go. That is a super major overhaul of the MediaWiki platform, has performance and storage implications. I think we should search for a solution using a mix of the following components:

1) Having a log table that contains user_id, app_id and timestamp so we can revert actions done by a particular user and app combination for a certain date range.

2) Having a policy where we clearly state under what circumstances we are free to to undo certain actions and ban a third party app.

3) The approval process by which we review third-party apps.

Drdee 03:58, 18 November 2011 (UTC)

We've been overhauling portions of MediaWiki for awhile, I see no reason to cut corners, not overhaul something that seams like it calls for it, and come out with a half-baked feature for something like this.

The only performance implications new columns have is in schema updates. New tables can also add other performance implications such as JOINS. So we're not going to get away with cutting corners and pretending that we shouldn't overhaul something and instead implement something that doesn't need to take the best decision for performance into account. Whether that's a column change or another table with say a pair of columns that point to a table and a primary key.

And something that doesn't properly associate the app/user to a change in an absolute way, especially something at the granularity of just a timestamp feels very fragile and liable to not work right.

What we're talking about here is code that will allow for a user session that only has partial permissions of a normal user session. Something that MediaWiki naturally was not coded to expect. Naturally it's possible that a feature like this will require a partial overhaul to make work correctly.

Also I don't like the idea of the core functionality of associating a change with an app being implemented in an extension. That seams like something that's liable to not be very compatible with extending into extensions. Some extensions add new api portions, and I'd hate to see an implementation of a feature that includes OAuth and the 3rd parties using it can't use something like LQT's api because LQT can't integrate the code needed to support OAuth in it's api. Or see that such a feature requires a bunch of tests all over extension code to ensure that the extension can actually work when the OAuth extension is not installed.