Using client credentials flow with scopes other than 'identify' on an app assigned to a team returns HTTP 400

[czaccardelli]

Description

When an app is assigned to a team and tries to specify scopes other than 'identify' in the OAuth2 Client Credentials flow when requesting a token, HTTP 400 is returned with the following body:

{"error": "invalid_scope", "error_description": "The requested scope is invalid, unknown, or malformed."}

Steps to Reproduce

Create an app. Assign it to a team. Using the client credentials flow using the client_id and client_secret, try to request a token while specifying scopes other than/in addition to 'identify'.

Expected Behavior

A token is granted.

Current Behavior

HTTP 400 with the following body is returned:

{"error": "invalid_scope", "error_description": "The requested scope is invalid, unknown, or malformed."}

Screenshots/Videos

N/A

Client and System Information

Tested using HttpClient in C# .NET 5.0. Windows 10 Build 19041

[advaith1]

it intentionally only works for identify and applications.commands.update; it wouldn't make sense for other scopes since teams don't have emails or connections and can't be in guilds

[czaccardelli]

Teams can't, but the apps that the teams build can. The client credentials flow is asking for authorization for the application itself, not the team. How could, for example, a Guild Slash Command be created by an app if it can't dynamically identify which guild it's in?

An app not on a team can access all scopes using the client credentials flow because it's an application and is requesting access as an application (I was actually surprised when my application returned my user details when it was registered under my personal account). Why then would authorization scopes suddenly not be allowed simply because the 'user' is a team? Users never factor into that OAuth authentication flow at all, nor should they.

[advaith1]

uh, the entire point of client credentials grant (with the exception of applications.commands.update now, although that used to give access to all the owner's bots' slash commands) is to authorize the application's owner, as the docs say:

The client credential flow is a quick and easy way for bot developers to get their own bearer tokens for testing purposes

The OAuth2 protocol as a whole is for authorizing users so I don't see what else you could expect it to do

[czaccardelli]

The OAuth2 protocol as a whole is for authorizing users so I don't see what else you could expect it to do

...except for the client credentials flow which is explicitly used when a client is

requesting access to the protected resources under its control

i.e. not on behalf of a user. A user does not factor in at all and I have never seen an implementation that returned a user as the subject/principal when authenticating using this flow.

https://tools.ietf.org/html/rfc6749#section-4.4
https://oauth.net/2/grant-types/client-credentials/

Aside from protocol implementations, the documentation specifically mentions using the client credentials flow with Slash Commands which makes applications added to arbitrary guilds unable to register Guild Slash Commands and do many other things because they have no context of where they are, who is using them, etc. Not to mention all this functionality works perfectly fine when an application is not registered under a team, so anyone trying to use it currently needs to not register their application under a team and just go back to the old superuser account stuff which is precisely the reason teams exist in the first place.

[advaith1]

so what would you expect client credentials grant to do for email, connection or guilds.join for apps in teams?? since when the app is owned by a user, those (in client credentials grant) give information about the application's owner.

as I said earlier, applications.commands.update (which appears to be your example) can be used by applications in teams, but that is the only OAuth2 scope which gives access to the application instead of a user or guild.

there is no actual functionality that apps in teams do not have currently

[czaccardelli]

as I said earlier, applications.commands.update (which appears to be your example) can be used by applications in teams, but that is the only OAuth2 scope which gives access to the application instead of a user or guild.

there is no actual functionality which apps in teams do not have currently

I think it's safe to assume the Discord API's OAuth implementation isn't going to be overhauled to treat applications as bot users are treated now even if that would be the more conventional approach (and apparently the direction Slash Commands are headed in).

That said, the proximate cause for raising this issue is that there's nothing in the documentation, API response, or anything else anywhere which says adding an application to a team will straight up make certain scopes invalid -- and even worse, that having them in the auth request will block token access in its entirety, leaving people scratching their heads (in my case, for a few hours) trying to figure out why legitimate scopes are being called invalid, unknown, or malformed -- especially when they work perfectly fine in other apps using the client credentials flow.

So yeah, at the very least update the error message returned so that it tells the person the requested scopes are not all valid for applications in a team. But since adding applications to a team is currently irreversible, it would be better to let people know before adding it to a team since they may potentially break their application by doing so

[night]

PRs for documentation improvements are welcome :)

Since this is not a bug and is working as intended though, I have closed this issue.