Restrict and document scopes that can be requested

[ckarlof]

If a whitelisted relier requests an unknown scope (e.g.a typo), it could be frustrating debugging experience why it doesn't work. In addition to profile, we got three others in the pipeline now: basket, makedrive, and galaxy.

[ckarlof]

Open question could be what we do in response to invalid scopes. Options:

• return error in GET /authorization
• just strip them out since https://github.com/mozilla/fxa-oauth-server/blob/master/docs/api.md#post-v1authorization could return a subset of requested scopes anyway.

[seanmonstar]

I think this has these downsides:

1. Adding service providers could be blocked on us. Currently, any can just get working, right away. It also requires more coordination to get it all working.
2. This goes in the opposite direction to eventually allowing random 3rd-party service providers from showing up and joining the ecosystem.

/cc @rfk since he mentioned interest at work week

[ckarlof]

We need to maintain a central collection of scopes for:

• documentation purposes
• localization purposes

I agree it may be nice to keep the OAuth server decoupled from the service providers to keep things moving fast. I'll change this to a doc bug and we can revisit restriction later.

[ckarlof]

I'm changing my mind, Changing this to a doc bug. I'm still concerned that if we allow service providers to go "cowboy" with the scopes we won't have a great way to track what scopes they are using so we can document and localize them properly. Have the fail fast if they aren't on a whitelist forces them to notify us so we can make sure they get documented and localized.

[ckarlof]

Easily adding new scopes would be a great use for our OAuth Management API and related CLI.

[ckarlof]

Another issue we need to careful about is to make sure that added scopes make their way through the system (dev -> stage -> prod).

[vladikoff]

got here via triage, what should we do about this @rfk ?

[rfk]

Let's revisit this as part of oauth/openid-connect work in Q4; hearting

[jwhitlock]

I got hit by this today, would love to see a documented list of scopes, and an endpoint that advertises them (like #257).

Ones that don't work (result ing errno 109, "Invalid request parameter"):

• profile (once upon a time it worked)

Ones that work:

• profile:email
• profile:avatar

Others?

[rfk]

profile (once upon a time it worked)

@jwhitlock this seems to be because you're marked as an "untrusted" client (i.e. one that's not hosted by Mozilla) which restricts the scopes that you can request. I'm surprised that "profile" scope ever worked in this configuration.

[jwhitlock]

It was working February 2015, probably before the trusted/untrusted distinction.

[rfk]

Ah, indeed, that distinction would have come in around March/April 2015. Thanks for clarifying!

[rfk]

🗡 ; we can bring this back as an issue in fxa-auth-server repo when we're ready to work on it.