Pleroma/Mastodon oauth should require no scopes

[tusooa]

Currently it is requiring "read," but this allows the app to see anything I can see, including any content privately addressed to me. This is too much permission. Here you are just trying to verify the identity, so you should not be allowed to read any private stuff.

[Changaco]

Liberapay does not request any specific scope when connecting a Mastodon or Pleroma account. I don't know if it's possible to explicitly request access to public information only.

[tusooa]

read scope is explicitly written when registering an app. When asking for user authorization, if the scope is not given, it defaults to the scope set when registering the app.

https://github.com/liberapay/liberapay.com/blob/master/liberapay/elsewhere/mastodon.py#L62

        data = {
            'client_name': self.app_name,
            'redirect_uris': self.callback_url.format(domain=domain),
            'scopes': 'read',
            'website': self.app_url,
        }

[Changaco]

OAuth Scopes - Mastodon documentation

If you do not specify a scope in your authorization request, or a scopes in your app creation request, the resulting access token / app will default to read access.

The set of scopes saved during app creation must include all the scopes that you will request in the authorization request, otherwise authorization will fail.

[Changaco]

A possible solution to this issue is to not use OAuth at all and verify ownership in another way (e.g. by asking the user to send a private message to a bot or add a public link to their Liberapay profile in their Mastodon settings).

[tusooa]

OAuth Scopes - Mastodon documentation

If you do not specify a scope in your authorization request, or a scopes in your app creation request, the resulting access token / app will default to read access. The set of scopes saved during app creation must include all the scopes that you will request in the authorization request, otherwise authorization will fail.

Use "scopes": "".

Specifying an empty value is not the same as not specifying.

At least on Pleroma, this works:

] curl -H 'content-type: application/json' https://lm.kazv.moe/api/v1/apps -d'{"client_name": "test", "redirect_uris": "https://gl.lm.kazv.moe/web/", "scopes": ""}'

and then GET /oauth/authorize?client_id=${clientId}&redirect_uri=${REDIRECT_URI}&response_type=code will give you an authorize page with no scopes specified.

[Changaco]

an authorize page with no scopes specified.

That's true, but the page doesn't actually work. Clicking on the “Approve” button results in an error message being displayed.

[tusooa]

Ummm, it turns out you can specify a fake scope

] curl -XPOST -H 'content-type: application/json' https://lm.kazv.moe/api/v1/apps -d'{"client_name": "test", "redirect_uris": "https://gl.lm.kazv.moe/web/", "scopes": "fake"}'

[Changaco]

https://github.com/liberapay/liberapay.com/pull/2156/commits/0f54c5f16dbfbdb5b3c348cf0763528414861640 reduces the permissions requested from Mastodon to read:accounts, so only data which isn't really sensitive will be accessible. Unfortunately Pleroma doesn't seem to support Mastodon's “granular” scopes, so the scope obtained from Pleroma will continue to be read.

[tusooa]

0f54c5f reduces the permissions requested from Mastodon to read:accounts, so only data which isn't really sensitive will be accessible. Unfortunately Pleroma doesn't seem to support Mastodon's “granular” scopes, so the scope obtained from Pleroma will continue to be read.

Pleroma does support read:accounts.

[Changaco]

After testing again, I've found that Pleroma does support granting the read:accounts scope, but not when the app was registered with scopes="read". This is a bug in Pleroma, and it significantly complicates things.

[tusooa]

The app should be registered with scopes="read:accounts".

[Changaco]

That would prevent requesting other read sub-scopes in the future if we need them. More importantly, we already have 169 apps registered in Pleroma instances with the read scope, we can't change them, we can't abandon them without losing access to the linked accounts, and in order to use different apps for different linked accounts we would have to make significant changes in our code (hence “it significantly complicates things”).

[tusooa]

A possible solution to this issue is to not use OAuth at all and verify ownership in another way (e.g. by asking the user to send a private message to a bot or add a public link to their Liberapay profile in their Mastodon settings).

Then I would say please go with this approach and set OAuth aside