---
title: Spring Security — Authorization Architecture (AuthorizationManager, Method Security)
source_type: official-doc
url: https://docs.spring.io/spring-security/reference/servlet/authorization/architecture.html
archive_url:
related_branches: [feature-authentication-authorization-contract]
related_projects: [ca-skeleton]
tags: [authorization, spring-security, AuthorizationManager, method-security, PreAuthorize, EnableMethodSecurity, official-doc]
created: 2026-06-08
last_reviewed: 2026-06-08
---

# Spring Security — Authorization Architecture (AuthorizationManager, Method Security)

> Layer: `raw/official-docs/` — Spring Security Reference 공식 문서. `Authorization Architecture` 페이지 + `Method Security` 페이지의 verbatim 발췌.
> feature-authentication-authorization-contract 의 enforcement mechanism axis 결정의 1차 근거.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-authentication-authorization-contract]] | `AuthorizationPort` 포트 추상화 vs `@PreAuthorize` 직접 사용 vs web-layer `authorizeHttpRequests` 비교 — Spring layer 분리 근거 |

## 출처 / Source

- 원본 URL: https://docs.spring.io/spring-security/reference/servlet/authorization/architecture.html
- 보조 URL: https://docs.spring.io/spring-security/reference/servlet/authorization/method-security.html
- 아카이브 URL: (미수집)
- 저자 / 조직: Spring Security (Broadcom / Spring team)
- 발행일: rolling docs (현재 = 6.x / 7.0.0 API 포함)
- 마지막 확인일: 2026-06-08

## 왜 저장했는지 / Why archived

Spring Security 의 `AuthorizationManager` 가 supersede 한 기존 `AccessDecisionManager` / `AccessDecisionVoter` 와 달리, `AuthorizationManager<T>` 는 **domain-neutral 인터페이스**이므로 application layer 에 Spring Security 타입 없이도 `custom AuthorizationManager<MethodInvocation>` 을 구현할 수 있다는 사실을 grounding 하기 위해.
`@PreAuthorize` 가 Spring AOP 를 통해 application layer 메서드에 직접 coupling 된다는 점도 기록.

## 핵심 인용 / Key quotes (verbatim)

> [§AuthorizationManager] "AuthorizationManager supersedes both AccessDecisionManager and AccessDecisionVoter. Applications that customize an AccessDecisionManager or AccessDecisionVoter are encouraged to change to using AuthorizationManager."

> [§AuthorizationManager] "AuthorizationManager instances make pre-invocation decisions on whether the invocation is allowed to proceed, and also post-invocation decisions on whether a given value may be returned."

> [§AuthorizationManager] "Implementations are expected to return a positive AuthorizationDecision if access is granted, negative AuthorizationDecision if access is denied, and a null AuthorizationDecision when abstaining from making a decision."

> [§AuthorizationManager interface] "The most common AuthorizationManager provided with Spring Security is AuthorityAuthorizationManager. It is configured with a given set of authorities to look for on the current Authentication. It will return positive AuthorizationDecision should the Authentication contain any of the configured authorities."

> [§GrantedAuthority] "By default, role-based authorization rules include ROLE_ as a prefix. This means that if there is an authorization rule that requires a security context to have a role of 'USER', Spring Security will by default look for a GrantedAuthority#getAuthority that returns 'ROLE_USER'."

> [§Method Security — @EnableMethodSecurity] "Then, you are immediately able to annotate any Spring-managed class or method with @PreAuthorize, @PostAuthorize, @PreFilter, and @PostFilter to authorize method invocations, including the input parameters and return values."

> [§Method Security — integration with application layer] "Spring Security's method authorization support is handy for: Extracting fine-grained authorization logic; for example, when the method parameters and return values contribute to the authorization decision. Enforcing security at the service layer. Stylistically favoring annotation-based over HttpSecurity-based configuration."

> [§Method Security — AOP coupling] "And since Method Security is built using Spring AOP, you have access to all its expressive power to override Spring Security's defaults as needed."

> [§Method Security — Custom AuthorizationManager] "This gives use access the entire Java language for increased testability and flow control." (replacing SpEL with a custom AuthorizationManager)

> [§Method Security — configuration] "You can place your interceptor in between Spring Security method interceptors using the order constants specified in AuthorizationInterceptorsOrder."

> [§Method Security — request-level vs method-level tradeoff table]
> "| authorization type | coarse-grained (request-level) | fine-grained (method-level) |"
> "| configuration location | declared in a config class | local to method declaration |"
> "| authorization definitions | programmatic | SpEL |"
> "The main tradeoff seems to be where you want your authorization rules to live."

> [§AuthorizationManagerFactory — Spring Security 7.0.0 API] "public interface AuthorizationManagerFactory<T> { AuthorizationManager<T> permitAll(); AuthorizationManager<T> denyAll(); AuthorizationManager<T> hasRole(String role); AuthorizationManager<T> hasAnyRole(String... roles); ... }"

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SS-AUTHZ-ARCH-C1 | Spring Security 6+ 에서 `AuthorizationManager` 가 `AccessDecisionManager` / `AccessDecisionVoter` 를 **supersede** 함 — migration 권장 | [§AuthorizationManager] "AuthorizationManager supersedes both AccessDecisionManager and AccessDecisionVoter. Applications that customize an AccessDecisionManager or AccessDecisionVoter are encouraged to change to using AuthorizationManager." | `official-vendor-doc` | Spring Boot 3.x / Security 6.x 환경 | `AuthorizationManager` 가 framework 외부 포트로 안전하게 추상화될 수 있다는 것까지는 증명 안 함 |
| SS-AUTHZ-ARCH-C2 | `@PreAuthorize` 는 **Spring AOP** 를 통해 동작하므로, annotated class/method 는 Spring-managed bean 이어야 하고 **Spring Security 의 SpEL 평가 인프라에 coupling** 됨 | [§Method Security] "And since Method Security is built using Spring AOP, you have access to all its expressive power..." + "you are immediately able to annotate any Spring-managed class or method" | `official-vendor-doc` | application layer use-case bean 에 `@PreAuthorize` 를 붙이는 패턴 | `@PreAuthorize` 가 Clean Architecture 를 위반한다는 것은 직접 증명 안 함 — 그것은 architectural constraint 에서 오는 결론 (INFERENCE) |
| SS-AUTHZ-ARCH-C3 | Custom `AuthorizationManager<MethodInvocation>` 을 구현하면 SpEL 대신 **pure Java** 로 authorization 로직을 작성할 수 있고, `@EnableMethodSecurity(prePostEnabled = false)` 후 custom interceptor 로 교체 가능 | [§Method Security] "This gives use access the entire Java language for increased testability and flow control." + custom interceptor configuration snippet | `official-vendor-doc` | application layer 에서 Spring Security 의존 없이 포트 인터페이스만 의존하는 설계 | custom `AuthorizationManager` 구현체 자체가 Spring-free 라는 것은 아님 — 구현체는 Spring bean 등록이 필요함 |
| SS-AUTHZ-ARCH-C4 | `authorizeHttpRequests` (web-layer rule) 은 **coarse-grained** 이며 config class 에 선언, method security 는 **fine-grained** 이며 method 선언에 local 함 | [§Method Security] tradeoff table — "authorization type: coarse-grained | fine-grained" | `official-vendor-doc` | web-layer URL rule 만으로는 use-case 별 permission check 가 불가능하다는 근거 | URL rule 이 완전히 대체 불가능하다는 것은 아님 — URL 이 1:1 로 use-case 에 매핑될 경우 가능 |
| SS-AUTHZ-ARCH-C5 | `ROLE_` prefix 는 Spring Security 의 **기본값** — role-based rule 은 `ROLE_` prefix 를 자동으로 붙임 | [§GrantedAuthority] "By default, role-based authorization rules include ROLE_ as a prefix." | `official-vendor-doc` | Keycloak realm role → `ROLE_*` authority 매핑 설계 | `ROLE_` 이 application-level permission 네이밍으로도 적합하다는 것은 아님 |
| SS-AUTHZ-ARCH-C6 | `AuthorizationManagerBeforeMethodInterceptor` + `AuthorizationManagerAfterMethodInterceptor` 로 pre/post authorization 을 **분리 구성** 할 수 있음 | [§Method Security] "Advisor preAuthorize(MyPreAuthorizeAuthorizationManager manager) { return AuthorizationManagerBeforeMethodInterceptor.preAuthorize(manager); }" | `official-vendor-doc` | use-case 전/후 authorization 분리가 필요한 설계 | 이것이 가장 Clean Architecture 친화적 패턴이라는 것은 증명 안 함 |

## Usage Boundaries / 적용 경계

- 이 자료가 직접 증명하는 것:
  - `SS-AUTHZ-ARCH-C1`: Spring Security 6.x 에서 `AuthorizationManager` 가 공식 표준 API
  - `SS-AUTHZ-ARCH-C2`: `@PreAuthorize` 는 AOP + Spring bean coupling 임
  - `SS-AUTHZ-ARCH-C3`: Custom `AuthorizationManager` 로 SpEL 을 Java 로 대체 가능
  - `SS-AUTHZ-ARCH-C4`: web-layer rule = coarse-grained, method-level = fine-grained
  - `SS-AUTHZ-ARCH-C5`: `ROLE_` 은 Spring Security 기본 prefix
- 이 자료가 증명하지 않는 것:
  - `@PreAuthorize` 를 application-core 에 두는 것이 Clean Architecture 위반인지 — 이는 프로젝트의 architectural constraint 에서 오는 판단
  - `AuthorizationPort` 포트 패턴이 `AuthorizationManager` 보다 낫다는 것
  - RBAC vs ABAC 선택 — OWASP / 별도 자료 위임
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  - application-core 모듈에서 `AuthorizationManager<MethodInvocation>` import 없이 포트 인터페이스만 의존하는 설계 패턴이 Spring Security 7.x 에서도 동일하게 작동하는지
  - `@EnableMethodSecurity(prePostEnabled = false)` 후 custom interceptor 만 활성화할 때 기존 Spring Security 보안 (CSRF, session 등) 에 영향이 없는지

## 메모 / Notes

- Spring Security 7.0.0 에서 `AuthorizationManagerFactory` 가 추가됨 (Spring Boot 3.5 에 포함 예정)
- `@PreAuthorize` 를 use-case (application-core) 에 직접 붙이면: (1) Spring Security 타입 import 필요, (2) AOP proxy 가 작동하려면 Spring bean 이어야 함, (3) SpEL 표현식은 compile-time 검증 없음 — 이 세 가지가 architectural constraint 위반 + 테스트 어려움의 원인
- Custom `AuthorizationManager` 는 `AuthorizationManager<MethodInvocation>` 을 구현하지만, 이 인터페이스 자체는 Spring Security import 임 → adapter layer (adapter-web) 에 두고, application-core 는 framework-free port interface 에만 의존하는 패턴이 필요

## Related / 관련

- [[raw/official-docs/security-authorization-cheatsheet-owasp]] — deny-by-default, least-privilege 원칙
- [[raw/official-docs/spring-security-resource-server-jwt]] — JWT authority mapping
- [[raw/branch-notes/feature-authentication-authorization-contract]]