Can I change app permissions when authorizing Github Apps?

[florianmartens]

Select Topic Area

Question

Body

I'm having trouble understanding the permission system when authorizing Github Apps (not OAuth Apps). I understand we can modify the permissions of our apps globally in their settings. These permissions, however, seem to only apply to installations of our apps.

Yet, I can retrieve an OAuth token via the ClientID my app exposes. However, the scopes feature does not seem to work for me...

Here is an example url:

https://github.com/login/oauth/authorize?response_type=code&client_id=xxx&state=xxx&redirect_uri=http%3A%2F%2Flocalhost%3A5173%2Foauth%2Fgithub%2Fredirect&scope=read%3Auser%20user%3Aemail%20read%3Aproject%20admin%3Aorg

When I check the page for my authorized apps I always see the following permissions:

Verify your GitHub identity
Know what resources you can access
Act on your behalf
View your email addresses

The authorization screen also looks unchanged in that it always shows email as the only requested resource. There is no mention of the extra scopes I requested.

What is going on here? Am I doing something wrong?

[florianmartens]

push

[ThisIs-Developer]

hey @florianmartens,

github apps use fine-grained permissions that are defined during installation. unfortunately, you can't modify those permissions dynamically when authorizing users. oauth tokens and scopes behave differently from github apps, and scopes won’t override the app’s global permission settings. make sure you're not mixing up oauth app scopes and github app permissions during setup

https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps
https://github.com/github/docs/blob/main/content/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps.md

hope that helps! feel free to mark it as an answer if useful! 😄

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[Dubz]

Is there any way this can be changed? It seems silly that we must accept whatever permissions are requested by a service just to use their app. There's no middle ground. I cannot say "I will use this service, but you cannot have x permission that you want." For instance, Cloudflare does not need "Read and write access to Administration". That's excessive reach and should not be required for users looking to connect the two for automatic deployments. All they need is their original "Read access to code and metadata" and "Read and write access to checks, deployments, and pull requests".

If I install an app before the permission is requested, and they later request it be changed, I can simply ignore it and continue to use it as-is. If their app ends up throwing errors as a result, that's on them to work around. We shouldn't be stuck forced to accept all or never use.

Why are we not practicing and encouraging the principle of least privilege here? This is a huge miss in security.

[SkiiOS]

You are not doing anything wrong what you are seeing is the intended behavior of GitHub Apps, which treat permissions and scopes fundamentally differently than legacy OAuth Apps.

Why the scope Parameter Is Ignored
In GitHub Apps, permissions are declared statically in your app’s settings rather than requested dynamically in the authorization URL.
OAuth Apps (Legacy): Scopes (like read:project or admin:org) are passed dynamically via the scope URL parameter during the authorization flow. GitHub Apps (Modern): The scope URL parameter in /login/oauth/authorize is ignored for app permissions. Instead, all repository, organization, and account permissions are defined directly in your app's configuration.

Why the Authorization Screen Always Shows the Same Permissions
When using a GitHub App's client_id with the /login/oauth/authorize endpoint, you are initiating the User-to-Server (User Access Token) flow.
Because GitHub Apps separate User Identity Authorization (identifying who the user is) from App Installation (granting access to specific repositories or organization resources), the initial web flow only prompts the user for identity consent.

The permissions you are seeing are the fixed defaults for user-level authorization:

• Verify your GitHub identity
• Know what resources you can access
• Act on your behalf
• View your email addresses (if email permission is enabled in app settings)