I mean quite often access based errors are very opaque, I mean it is for good reason, but when you're new to something it's one of those things that leads you to give up. You want to write code, not spend 3 hours figuring out why your token doesn't work.

Security things will get hacked on later, but again it will cause all kinds of problems because the ecosystem wasn't built for it.

▲

ants_everywhere 3 days ago | parent [-]

> quite often access based errors are very opaque

Yes they are, and it's hard to design good scopes especially when the project is new.

A better default might just be to have the write permission expire much more quickly than the read permission. E.g. the write token might be valid for an hour and the read token might be valid for 90 days.

	▲	danudey 2 days ago \| parent [-]
		Two things I really wish literally any company would ever do with their systems when you have a permissions-based token: 1. Show me all the permissions that that token has been granted but has never used 2. Show me all the permissions that that token has tried to use but does not have I would gladly accept the ability to turn on an audit mode for a given token, service account, etc., run the thing I'm trying to run, and then go look at the report to see what permissions I can remove - or, even better, have a giant "Create role from this profile" that lets me create a custom set of permissions based on all of the permissions I've used. Google Cloud does have a thing where it shows you all the service accounts you have with "overly broad permissions", but it seems to be just "here are all the SAs with 'owner' access" so far. It didn't catch the service account we had that just needed to publish one file to one bucket but had been made a Storage Administrator with full read/write/update/delete access to every form of storage in Google Cloud.