You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seems that at present auth0 requires the Admin Role on a tenancy. It would be good to support other roles, e.g. Viewer access for logs.
At present a Viewer role gets a failure message "We are not able to activate your device." from the activate URL, and "User is not authorized.." from the CLI.
Describe the ideal solution
I believe this would be accomplished by way of specifying the desired scopes at logon. auth0 login --scopes is documented as adding the given scopes; there appears to be no means on reducing or explicitly expressing the desired scopes as is needed for the above.
there needs to be an new option that allows explicitly setting scopes; ideally the existing option would be renamed to be --add-scopes and the new option would then be --scopes
failing that, maybe: rename --scopes as --scopes-add (deprecate --scopes), add --scopes-set and a --scopes-del for good measure (i.e. where it's simpler to express what you want as the default set minus a few scopes)
the default Admin Role requirement / presumption re. scopes should be documented
Currently in auth0-cli, you can perform a machine login by providing your client credentials. This allows you to configure your client with a specific client grant and set the desired scopes accordingly. By specifying the appropriate scopes for your client grant, you can enable non-admin role such as Viewer access for logs without requiring full Admin privileges.
Hi @ramya18101 ; I expect using client credentials would likely allow me to specify the desired scopes. However for interactive use where the person using auth0 has an Auth0 Team/tenancy membership, it's far preferable - and far more secure - to use the user flow.
Whilst creating a client for the auth0 use case, and using machine auth, may be a workaround for being unable to use auth0 as a non-Admin role, I don't see it as a practical one.
TBC: people with Viewer roles need to be able to use auth0, just like they can use the web dashboard.
Internally, when accessing logs with viewer permissions, the Management API’s GET calls are handled using a cookie-based approach. Achieving true viewer-level access isn’t solely a matter of adjusting scopes, there are additional internal mechanisms and dependencies on the Management API that would need to be addressed to fully support this capability.
At this stage, We’d like to park this in discussions for now and gauge the community’s feedback.. Basis on traction, we can look into exploring it further and potentially include it in our roadmap.
Thanks again for your feedback and for helping us improve the Auth0 CLI!
Activity
ramya18101 commentedon Jul 24, 2025
Hello @ad8-bdl ,
Currently in auth0-cli, you can perform a machine login by providing your client credentials. This allows you to configure your client with a specific client grant and set the desired scopes accordingly. By specifying the appropriate scopes for your client grant, you can enable non-admin role such as Viewer access for logs without requiring full Admin privileges.
ad8-bdl commentedon Jul 25, 2025
Hi @ramya18101 ; I expect using client credentials would likely allow me to specify the desired scopes. However for interactive use where the person using
auth0has an Auth0 Team/tenancy membership, it's far preferable - and far more secure - to use the user flow.Whilst creating a client for the
auth0use case, and using machine auth, may be a workaround for being unable to useauth0as a non-Admin role, I don't see it as a practical one.TBC: people with Viewer roles need to be able to use
auth0, just like they can use the web dashboard.ramya18101 commentedon Jul 30, 2025
Internally, when accessing logs with viewer permissions, the Management API’s
GETcalls are handled using a cookie-based approach. Achieving true viewer-level access isn’t solely a matter of adjusting scopes, there are additional internal mechanisms and dependencies on the Management API that would need to be addressed to fully support this capability.At this stage, We’d like to park this in discussions for now and gauge the community’s feedback.. Basis on traction, we can look into exploring it further and potentially include it in our roadmap.
Thanks again for your feedback and for helping us improve the Auth0 CLI!