@PreAuthorize, @Secured, @RolesAllowed는 모두 Spring Security에서 메소드 수준의 보안을 적용하는 어노테이션들이지만, 각각의 작동 방식과 기능에 차이가 있다.
1. @PreAuthorize
메소드 호출 전에 특정 조건(권한, 역할 등)을 만족하는지 검증할 수 있는 어노테이션입이다.. 메소드 실행 전 권한을 동적으로 체크하며, SpEL (Spring Expression Language)을 지원하여 매우 유연한 권한 검사를 할 수 있다.
@PreAuthorize("hasRole('ROLE_ADMIN') or hasAuthority('MASTER')")
//@PreAuthorize("hasRole('ROLE_ADMIN')") //역할(role) 기반 검증
//@PreAuthorize("hasAuthority('MASTER')") //권한(authority) 기반 검증
public void someMethod() {
// ADMIN이거나 MASTER일 경우에만 실행됨
}역할 기반 검증의 경우 Spring Security는 hasRole을 사용할 때 자동으로 ROLE_ 접두사를 붙인다. 예를 들어, hasRole('ADMIN')라고 지정하면 실제로는 ROLE_ADMIN 역할을 찾는다.
권한 기반 검증인 hasAuthority는 hasRole과 달리 접두사를 자동으로 붙이지 않으며, 사용자가 제공한 문자열 그대로 권한을 검사한다.
@PreAuthorize의 경우 역할(Role)뿐만 아니라 권한(Authority)도 유연하게 설정 가능하며, 복잡한 조건을 표현할 수 있으므로, 복잡한 권한 로직이 필요한 경우 주로 사용된다. 가장 유연하고 파워풀한 어노테이션이기 때문에 자주 사용되는 방식이다.
2. @Secured
역할(Role) 기반의 간단한 보안을 설정할 수 있는 어노테이션이다. Spring Security의 전통적인 방식으로, 특정 역할을 요구하는 간단한 경우에 주로 사용된다. SpEL을 지원하지 않으며, 권한 검증에 있어서 다소 제한적이다.
@Secured("ROLE_ADMIN")
public void someMethod() {
// ROLE_ADMIN 있을 경우에만 접근 가능
}설정이 간단하지만 복잡한 권한 검증에는 적합하지 않으며 역할(Role)만을 지원한다. 실제로 간단한 권한 관리가 필요한 곳에서는 사용되지만, 스프링의 유연성을 살리기 어려운 경우가 많아 현업에서는 많이 사용되지는 않는다.
3. @RolesAllowed
JSR-250 표준에 따라 역할(Role) 기반으로 접근 제어를 하는 어노테이션이다. Java EE의 표준이기 때문에 Spring과 Jakarta EE를 함께 사용하는 경우 유용하다. @Secured와 비슷하게 동작하며, 역시 SpEL을 지원하지 않는다.
@RolesAllowed("ROLE_ADMIN")
public void someMethod() {
// ROLE_ADMIN 있을 경우에만 실행됨
}Java 표준이므로 비 Spring 환경에서도 사용할 수 있는 이점이 있다. 하지만 복잡한 권한 로직을 다루기에는 한계가 있다. 주로 Java EE 기반의 프로젝트에서 사용되며, Spring 프로젝트에서는 @PreAuthorize가 더 선호된다.
