Spring Security: Authority and GrantedAuthority
Spring Security represents permissions and roles as authorities associated with an authenticated principal. A `GrantedAuthority` is the framework abstraction used to represent each authority during authorization checks.
An authority is a string-like permission value that Spring Security can use when deciding whether an authenticated user may perform an operation. Examples include `ROLE_ADMIN`, `ROLE_USER`, and `READ_REPORTS`.
`GrantedAuthority` is the Java interface representing such an authority. Its main method, `getAuthority()`, returns the authority value as a `String` when the value can be represented in that form.
Authorities are normally associated with an `Authentication` object. The authenticated principal has a collection of `GrantedAuthority` objects, and authorization mechanisms inspect that collection when evaluating access rules.
Roles are commonly represented as authorities with the `ROLE_` prefix. For example, a user granted the role `ADMIN` is commonly checked through an authority named `ROLE_ADMIN`; role-based APIs may apply the prefix automatically depending on the API being used.
A key interview distinction is that `GrantedAuthority` is the representation used by Spring Security, while a role or permission is the application-level meaning assigned to that authority. The authority itself does not automatically grant access everywhere; an authorization rule must actually check it.
Key points
- `GrantedAuthority` represents an authority used by Spring Security authorization.
- Authorities are attached to the authenticated `Authentication` object.
- `getAuthority()` supplies the string representation when one exists.
- Roles commonly use the `ROLE_` prefix, such as `ROLE_ADMIN`.
- Authorities can represent either roles or more fine-grained permissions.
Interview questions
What is `GrantedAuthority` in Spring Security?
`GrantedAuthority` is an interface used by Spring Security to represent an authority granted to an authenticated principal. Its `getAuthority()` method provides the authority's string value when it has a string representation. A common implementation is `SimpleGrantedAuthority`. Authorization checks can use these authorities to determine whether access should be allowed.
How are roles represented as authorities?
Spring Security commonly represents roles as authorities whose names start with `ROLE_`. For example, the role `ADMIN` is typically represented by the authority `ROLE_ADMIN`. APIs for role checks may handle the role prefix convention for you, so the exact expression used in configuration matters.
Can a `GrantedAuthority` represent a permission instead of a role?
Yes. A `GrantedAuthority` is not limited to roles. Applications can use authority values such as `READ_REPORTS` or `INVOICE_APPROVE` to model fine-grained permissions. Authorization rules can then check those values directly, commonly through authority-based checks.
Where do a user's authorities live in Spring Security?
They are exposed through the authenticated `Authentication` object. The authentication contains the principal information together with a collection of `GrantedAuthority` instances. Authorization components can inspect that collection when making access decisions.
What is the difference between `hasRole` and `hasAuthority`?
Both are authorization checks, but they express different conventions. `hasRole` is intended for role-style authorities and commonly applies the `ROLE_` convention, whereas `hasAuthority` checks the supplied authority value directly. Therefore, a check for `ADMIN` using a role-oriented API can correspond to the authority `ROLE_ADMIN`, while an authority-oriented check can explicitly test `ROLE_ADMIN` or another permission string.