3 ms·

For a while now I've been worried about this -- either integrations asking for full read/write access for a service that might seem to need only read. Or mayb

For a while now I've been worried about this -- either integrations asking for full read/write access for a service that might seem to need only read. Or maybe worse, integrations asking for access to anything my account has access to, when I only want to grant it to one repo or organization, or only to public repos and not private ones. Whenever I've reached out to inquire/complain about this, I've been told that github does not give them granular enough auth settings to ask for less than this. Is this true? I don't know. When I've tried looking at the relevant github docs myself, i quickly get confused. Does anyone understand the github auth architecture -- does it need to be fixed to allow more granular access, or are integrations just not using it properly? Like... who should I be complaining to?

whelton 5y ago
I've been looking into this as I'm building similar per resource scoping for conjure.so's API. GitHub has 'OAuth Apps' and 'GitHub Apps' [0]. The former's scopes do not permit such granularity (eg the `repo` scope gives access to all repos of the account [1]). The latter is much more granular, allowing the user to select specific repos to grant permission [2]. The 'GitHub App' owner can see their installations and also determine if the user chose access for all repos or on a per repo basis. Netlify does such granular installation and will prompt you if you don't see your repo listed in their dashboard to check permissions. [0] https://docs.github.com/en/developers/apps/getting-started-with-apps/differences-between-github-apps-and-oauth-apps#what-can-github-apps-and-oauth-apps-access https://docs.github.com/en/developers/apps/getting-started-w... [1] https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes https://docs.github.com/en/developers/apps/building-oauth-ap... [2] https://docs.github.com/en/developers/apps/managing-github-apps/installing-github-apps#installing-your-private-github-app-on-your-repository https://docs.github.com/en/developers/apps/managing-github-a...
- ethbr0 5y ago
  Ironically, Slack seems to have really homed in on granularity of integration access as a key feature as well. Which makes sense... but then so many companies don't do that.
- jrochkind1 5y ago
  Do you think that still sounds much more confusing than it needs to be? I don't totally understand why they offer these two mechanisms of integration -- or why the granularity of access would need to be different between them. Why not let "OAuth apps" be authorized per-repo -- if you are going to have "OAuth apps" existing as a thing still? And they don't seem to be deprecated in favor of newer "github apps", right?
  - whelton 5y ago
    Yeah agreed its pretty confusing and took me some time to reconcile! I imagine for legacy support or business reasons they maintain the OAuth API, but I too wish they add granular repo support to the OAuth API and existing tokens were migrated to an all repos scope, while new tokens were encouraged to be per repo scoping.
deleted 5y ago
[deleted]

whelton 5y ago

I've been looking into this as I'm building similar per resource scoping for conjure.so's API. GitHub has 'OAuth Apps' and 'GitHub Apps' [0]. The former's scopes do not permit such granularity (eg the `repo` scope gives access to all repos of the account [1]). The latter is much more granular, allowing the user to select specific repos to grant permission [2]. The 'GitHub App' owner can see their installations and also determine if the user chose access for all repos or on a per repo basis. Netlify does such granular installation and will prompt you if you don't see your repo listed in their dashboard to check permissions. [0] https://docs.github.com/en/developers/apps/getting-started-with-apps/differences-between-github-apps-and-oauth-apps#what-can-github-apps-and-oauth-apps-access https://docs.github.com/en/developers/apps/getting-started-w... [1] https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes https://docs.github.com/en/developers/apps/building-oauth-ap... [2] https://docs.github.com/en/developers/apps/managing-github-apps/installing-github-apps#installing-your-private-github-app-on-your-repository https://docs.github.com/en/developers/apps/managing-github-a...

ethbr0 5y ago
Ironically, Slack seems to have really homed in on granularity of integration access as a key feature as well. Which makes sense... but then so many companies don't do that.
jrochkind1 5y ago
Do you think that still sounds much more confusing than it needs to be? I don't totally understand why they offer these two mechanisms of integration -- or why the granularity of access would need to be different between them. Why not let "OAuth apps" be authorized per-repo -- if you are going to have "OAuth apps" existing as a thing still? And they don't seem to be deprecated in favor of newer "github apps", right?
- whelton 5y ago
  Yeah agreed its pretty confusing and took me some time to reconcile! I imagine for legacy support or business reasons they maintain the OAuth API, but I too wish they add granular repo support to the OAuth API and existing tokens were migrated to an all repos scope, while new tokens were encouraged to be per repo scoping.

deleted 5y ago

[deleted]