The binder service also should not need to be admin, we should define Binder's own permissions in a role. It needs:
servers to read, start, and stop user servers
admin:users (if not using auth)
It may make sense to define the role(s) dynamically in Python, because of the if auth_enabled logic involved. Or we could define two roles statically in config, and then assign the role dynamically, depending on if auth is enabled or not.
Alternately, it could get no permissions at all in the auth case, and we could perform the launch requests with the user's own token. That might be better! It would mean specifying the permission servers!user in the services.binder.oauth_client_allowed_scopes config. It would still mean defining the (default) binder role (or not) and then assigning it (or not) based on auth_enabled.
As @minrk commented in https://github.com/jupyterhub/binderhub/pull/1544#issuecomment-1277497482, it is now possible to reduce the JupyterHub API permissions requested by binderhub with JupyterHub's new RBAC system.