Authorize does not support scope/permissions

[TheCodeKing]

This is a feature request.

I would like to be able to use the /authorize endpoint to generate an access_token with a particular scope. As a minimum, I'd like to at least lock it down by team.

Read-only access and site-level access would also be preferred.

[nolessafool]

Thanks for the suggestion! You didn't miss anything - we don't have team-based authentication tokens at present though there is an open feature request which I'll link this issue to so we can let you know if we ship it.

We don't have any intentions to make a read-only or site-level token right now. Could you elaborate on your use case there so we can either capture it as a new feature request or advise you on better paths to achieve what you're after?

[TheCodeKing]

Exposing an access token in env variables for example and/or using in code to communicate with the Netlify API. There's a case for wanting to ensure this is read-only. In particular when there's no way to scope tokens to a team. We don't want anyone working on a team to have full access to every other team/site.

Another feature request is to protect environment variables from being plain-text readable via the UI. Again anyone with access to the UI can see sensitive information which we might not want everyone on the team to have access to.

[nolessafool]

The usual way to handle team-member level permissions on individual team-owned sites is to...use the site-level permissions :) You can invite people to collaborate on only one or a few sites on a team. Then their access tokens won't allow them to do anything on other sites. Is there some reason this won't work for you for that particular use case? If so please elaborate so I can either find you some better advice or get a feature request filed.

Re: read-only, I can guess what you want, but could you elaborate on an example situation in which you want people to be able to see, but not manipulate, all site settings? We do already have provisions for exposing build logs and not site settings to non-team-members, in case that is your goal. Anyway I am not trying to be a jerk, just to get this request into the best shape for a feature request that could succeed rather than one that will be ignored for a lack of details, so appreciate your help in getting me there :)

Re: obfuscated environment variables we are working on that already but this has gone very far from an open-api feature request so if you want to track that work could you please ping our helpdesk (support@netlify.com) and link to this thread (on GH), so we can attach your contact info to that work, to notify you when it ships?

[TheCodeKing]

That works fine when using access tokens in development, where each member keeps this personal. In production however, we use a token in an env variable. Anyone can view these and use them, and then it's the issue that it exposes all sites/teams that that team member's token has access to.

[nolessafool]

I apologize for being dense, but I am not sure of the answers to either of the questions I asked and this understanding will be required for me to file good feature requests. Hopefully the annoyance of explaining things to a fool is trumped in the interest of getting actionable feature requests filed - without those, this conversation will have no results that may help you.

1. you want individual Netlify API access tokens, and for that I still don't understand why you'd allow people read-only access to site settings that they couldn't manipulate. In that case, don't allow them access to the site settings at all (make them collaborators only on sites where they should be able to see the settings; they can browse any site they want and even see its build logs if we configure things that way, without any access to site settings). Is that not possible in your workflow? This was a large part of why we designed teams the way we did - you as a team owner can limit folks' access to only sites they should be able to see all settings for. You wouldn't put "high security" auth tokens in those sites' settings, in the world we imagined.

2. you want read-only access to ???

3. I don't know if you pinged us in the helpdesk around obfuscated tokens but that is one you don't have to explain further since we already are in agreement and working on that :)

[TheCodeKing]

Sorry I prob didn't explicitly answer your questions. Let me try again.

1. There are cases where we want to display information from Netlify APIs, on a say a custom dashboard. a) The reason for wanting this read-only is because the access token is currently only scoped to a team member, and therefore exposes full admin access to other sites and teams they have access to. b) For read-only information, we would also want to lock down the surface area for attack by limiting the scope of the access token and ensuring it can't be used to modify sites either accidentally or maliciously - especially sites the other team members aren't members of.

2. Read-only as in not be able to modify sites, deploy or change in any way. So still be able to list sites for a team and read the data from the API - partly addresses 1 b) and allows us to share a token in an env variable without risk of it being abused.

3. No, I'll just wait for the feature to become available. This does mitigate some of the issues discussed above, as at least then the token from one member is not exposed directly to other team members.

I think basically what we need are application level tokens that can be scoped to a particular site. That as a minimum with the obfuscated variables allows us to work across teams/clients without having to expose member level access to others.

[nolessafool]

Thanks for that explanation! The bit about the low permission token for the dashboard type usage, and ability to see nonprivileged settings for a site now makes perfect sense to me. I've encapsulated in a feature request that I'll link here (you can't see it, but the act of linking it enables us to get in touch while we design the feature for more feedback or invite you to beta test or at least inform you it has shipped!)

However, I'm still not understanding why you need a token scoped to a single site - our advice is to use a collaborator invited only to a single site instead and their token will have access to only the one site. Our API tokens are login/account based and I do not expect that to change, so whether or not that's exactly what you are hoping for - that may be the best solution for that particular situation regardless of whether we come up with more granular token permissions or new account roles (e.g. read-only) for an account/login

TL;DR I'd need to hear more about why the user permissions can't be used to limit API access to some subset of sites before I could file a feature request on that topic.

We won't be able to notify you about the release of the obfuscated tokens feature if you don't ping us in the helpdesk, is why I asked you to do that. If you feel confident you'll find it on your own that's fine with me :)

[TheCodeKing]

So we can invite a collaborator to a single site. The issue is if I use my access token for an application in an env variable for example. This provides full access to all the sites and teams that I'm a member of, not what the invited member is a collaborator of. Likewise, if the invited member uses their access token in an env variable, it would allow me access via the token to all the other sites and teams that member is a collaborator of. The issue is that tokens are scoped per user and not scoped to a site or team. This works for developers who can use their personal tokens but breaks when the token becomes part of an application.

For this, I would hope to use an OAuth application token rather than a personal token, but surprisingly this is also scoped to a user permissions. It also means if I integrate with a third party over OAuth, they have access to everything I do, and not a particular team/site that integration might be relevant to. Working across clients, it means 1 client's data may be exposed where it shouldn't be, and because of another client.

[pixelastic]

Interested in having tokens scoped to a specific site as well.

Here is an example of an implementation that could benefit from it:

As part of my Netlify and CircleCI builds, I sometimes need to call the Netlify API to perform some tasks (for example triggering/cancelling a specific build). Those calls need to be authenticated, and I have been using a NETLIFY_AUTH_TOKEN env variable for that.

The issue is that this NETLIFY_AUTH_TOKEN is user-scoped, and thus can do anything on I, as a user, can do. It sure can trigger/cancel builds, but can actually do it on any site I have access to. If the NETLIFY_AUTH_TOKEN leaks (and it will, given enough time), then all my sites are compromised and not only the one site I used it on.

You mentioned fixing those issues through user permissions. That seems reasonable, but is it possible to create "fake" users, not linked to real people, but only used for automation, a bit like GitHub bot accounts?

[deni]

Any updates on this? It seems that the documentation incorrectly claims support for scoped access:
https://docs.netlify.com/configure-builds/repo-permissions-linking/#authentication-with-the-netlify-github-app