As already mentioned in Lie Ryan's answer, Kerckhoff's principle applies here. Granting knowledge, to a user of his resources on a system should not increase vulnerability of that system. If you think it does, you have some bigger problems to consider first.
The first thing to do with your system: Assess whether giving knowledge of how that system works increases hazard in the first place.
If it does increase hazards, you may have bigger problems than simply whether a user can view their own authorizations, and need to lock down any other knowledge of that system.
Furthermore, is hiding a user's authorizations is a condition of reducing your system's vulnerability? If so, you are setting yourself up for failure.
This is because, in a properly available system, a user can pretty easily discover their capabilities over time, simply by using the system in question, and recording what they can and cannot do. This applies even if the system is a method of troop deployment because, hey, your users are going to have to, well, use it.
In fact, a user's knowledge of what's available to him is often a condition of availability in the first place.
And an unavailable system has failed already.
Back to Kerckhoff's principle, here are some questions to check whether you're in a "security through obscurity" type of situation are:
Is the related code or specification for your system open-source?
Do others using similar systems also restrict this information
If not, has it lead to increased hazards for them?
What scenarios can you think of where allowing this info to all users would make the system vulnerable? And does restricting the information actually reduce vulnerability (compared to alternatives)?
Here is a worked example, using 2 of my Blue Team security tools of choice, KeePassXC and HashiCorp Vault:
Yes KeePassXC, HashiCorp Vault
KeePassXC: No, because the authorization is limited to which KeePassXC DBs to which you have passwords and keys.
HashiCorp Vault: No
KeePassXC: Nope. If you do not name your DB after any of your passwords, you're golden.
HashiCorp Vault: No, as long as you don't name the stuff that's used in the authorization method (e.g. KV store names) to hold secret data Again, there is some responsibility on the user, here. If you respect the boundaries, and don't name your DBs and your KVs after usernames or passwords, this does not introduce a new vulnerability.
Here is a scenario where vulnerability is increased by a user's knowledge of his own access:
A. Where the user already has privileged access he should not, and simply wouldn't know it otherwise.
In this case, it would be prudent to restrict the user's knowledge. But a better alternative is to just reduce the access levels in the first place, rather than just restricting his knowledge of his own access, because he may discover his available resources accidentally anyway. If you're in a situation where you've named your KeePassXC DB or HashiCorp Vault KV key names after something privileged, they both have ways to move that information further down to where it's not exposed to the authorization system. For the example in Vault's KV store, just change the Key names to something generic, and copy the privileged information to secure values of those Keys.