[OAuth] Spring Authorization Server로 인가 서버 직접 구축하기

Daehwan Kim·2026년 1월 22일

OAuth

목록 보기

3/3

1. 서론

이번 글에서는 Spring Boot 기반으로 OAuth 2.1을 중심으로 한 인가 서버(Authorization Server)를 직접 구축해볼 것이다.

그 전에 부트캠프에서 직접 인가 서버를 구축하기 위해 Spring Authroziation Server 공식 문서를 찾아봤었다. 그 때, 특이하게 Spring Authorization Server가 OAuth 2.0이 아니라 OAuth 2.1을 기반으로 구현되어 있다는 점이었다.

OAuth 2.1은 아직 IETF 초안(draft) 상태인데, Spring에서 이를 기반으로 공식 인가 서버 구현체를 제공하고 있었다는 점이다.

앞선 포스팅에서 다루었듯이, OAuth 2.1이 새로운 개념을 제시한다기 보다, OAuth 2.0에서 오랫동안 문제로 지적되던 요소를 정리하고, 이후 사실상 표준으로 자리 잡은 보안 사례들을 하나의 흐름으로 재정립 한 결과에 가깝다.

Spring Authorization Server이 공식 문서에서 OAuth 2.1를 기반으로 구현되었다는 것이 결국 나를 여기까지 오게 만들었다.

이어 Feature List에도 OAuth 2.1 Authorization Framework(draft)를 중심으로 하되, 여전히 OAuth 2.0의 여러 사양과 확장 요소들이 함께 구성되어 있는 것을 볼 수 있다.

따라서 이번 글의 최종 목표는 다음과 같다.

Spring Authorization Server의 최신 구조 이해
바로 적용가능한 OAuth 2.1 Authorization Code Flow + PKCE(Proof Key for Code Exchange) 기반 인증 서버 구축

2. 인가 서버의 의존성 구성

2.1 Spring Authorization Server 구성

Spring Authorization Server 기반 인가 서버를 구성하기 전에 먼저 관련된 프로젝트의 버전 관계를 정리할 필요가 있다.

먼저, Spring Authorization Server는 인가 서버의 기능을 빠르게 개발하기 위해 Spring Security와 분리된 프로젝트로 시작했다. 이후 인가 기능과 구조가 안정화가 됨에 따라서 Spring Authorization Server가 Spring Security 7.0에 공식적으로 통합되었다.

위 Spring 블로그 글에서도 동일하게 설명하고 있다.

Spring Authorization Server 1.0버전은 Spring Security와 별개의 프로젝트로 시작하여 빠른 기능 개발을 진행할 수 있었으며, 시스템이 안정화가 됨에 따라 Spring Security 7.x 버전으로 이전됨.

즉, 앞으로는 인가 서버의 기능은 Spring Security 7.0부터 통합되었다.

그런데, 다음 Spring Security 가이드에서 Spring Security 7.0 이상을 사용하기 위해서는 Spring Boot 4.0 이상을 사용해야한다.

결론적으로는 안정화된 Spring Authorization Server를 사용하기 위해서는

Spring Boot 4.0 이상
Spring Security 7.0 이상
를 사용해야 공식적으로 지원되는 최신 인가 서버 기능을 사용할 수 있다.

2.2 의존성 설정

위 기준을 바탕으로 Spring Initialzr를 통해 다음과 같이 프로젝트와 의존성을 설정했다.

필요한 핵심 의존성은 다음과 같다.

Spring Security: 보안 필터 체인, 토큰 처리 전반을 담당
Spring Web: HTTP 요청/응답 처리
OAuth2 Authorization Server: OAuth 2.1/OpenID Connect(OIDC) 인가 서버 의존성

OpenID Connect(OIDC)를 간단히 정리하자면,
OAuth 프레임워크 위에 인증(Authentication) 계층을 추가한 사양이다. 본 포스팅에서는 인가 서버 구현에 집중하며, OpenID Connect는 이후 별도의 글에서 다룰 예정이다. 알아야할게 정말 많은 것 같다. 개발자 모두 파이팅이다.

추가로 DB 및 영속성 계층으로는 다음 의존성을 추가했다.

Spring Data JPA: JPA 기반 영속성 추상화 ORM 계층
Lombok: 반복되는 보일러플레이트 코드 제거를 위한 도구
postgreSQL: 인가 서버의 엔티티 구조를 확인하기 위한 관계형 데이터베이스

Spring Authorization Server는 기본 구현으로 JDBC 기반 저장소 구현체( JdbcRegisteredClientRepository)를 제공한다.

JDBC를 기본 구현으로 제공하는 이유는 의존성이 낮아 빠르게 최소 구현을 달성하기 위함으로 생각된다. 그러나, 실제 서비스 환경에서 JDBC는 도메인 확장 등의 어려움이 있다.

그래서 공식문서에 따르면, "How-to: Implement core services with JPA" 가이드를 제공하며, 이를 기반으로 각 서비스 구현을 프로젝트 요구에 맞게 수정하려 한다.

또한, Lombok도 사실상 표준인 기술이므로 추가했다.

3. 인가 서버 구현

Spring Authorization Server: Getting Start를 기준으로 구현을 진행하되, 실제 서비스에 바로 적용할 수 있는 수준을 목표로 구성 요소를 재정히하면서 구현하고자 한다.

그리고 단순히 코드를 나열하기보다는 Authorization Code Flow + PKCE를 기준으로 각 단계에서 어떤 요청이 발생하고, 그에 따라 어떤 코드와 설정이 동작하는지를 전체 흐름 중심으로 살펴본다.

3.1 `application.yml` 기반 최소 구성 방식

(1) `application.yml` 자동 구성 방식의 특징

application.yml 기반 설정은 Spring Authorization Server 공식 문서에서 가장 먼저 소개되는 방식이다.

OAuth2 Authorization Server 의존성만 있으면, Spring Boot의 자동 구성에 의해 필요한 @Bean들이 자동으로 등록되어 인가 서버의 최소 구현이 가능하다.

server:
  port: 9000

logging:
  level:
    org.springframework.security: trace

spring:
  security:
    user:
      name: user
      password: password
    oauth2:
      authorizationserver:
        client:
          oidc-client:
            registration:
              client-id: "oidc-client"
              client-secret: "{noop}secret"
              client-authentication-methods:
                - "client_secret_basic"
              authorization-grant-types:
                - "authorization_code"
                - "refresh_token"
              redirect-uris:
                - "http://127.0.0.1:8080/login/oauth2/code/oidc-client"
              post-logout-redirect-uris:
                - "http://127.0.0.1:8080/"
              scopes:
                - "openid"
                - "profile"
            require-authorization-consent: true

이 구성에서는 OIDC를 포함한 자동 구성 예제이다.

위 설정을 통해 인가 서버가 정상적으로 구성되었는지 확인해보자.
다음은 OAuth 인가 서버에서 제공되는 메타데이터 엔드포인트이다. 이를 통해 확인할 수 있다.

http://localhost:9000/.well-known/oauth-authorization-server

이 엔드포인트는 OAuth 2.0 Authorization Server Metadata(RFC 8414)에 정의돈 표준 엔드포인트로 OAuth 클라이언트가 인가 서버의 기능과 엔드포인트 정보를 JSON 형태로 자동 설정하기 위해 사용된다.

JSON 응답 중, 최소한의 인가 서버 구성이 완료되었는지 확인할 수 있는 항목은 다음과 같다.

구분	필드명	설명
식별	`issuer`	Authorization Server의 고유 식별자, 토큰의 `iss` 클레임 검증 기준
인가	`authorization_endpoint`	Authorization Code Flow에서 인가 코드를 요청하는 엔드포인트
토큰	`token_endpoint`	Access Token 및 Refresh Token 발급 엔드포인트
클라이언트 인증	`token_endpoint_auth_methods_supported`	토큰 엔드포인트 호출 시 허용되는 클라이언트 인증 방식
응답 유형	`response_types_supported`	인가 엔드포인트가 지원하는 응답 형식 (`code`)
그랜트	`grant_types_supported`	인가 서버가 허용하는 Grant Type 목록
PKCE	`code_challenge_methods_supported`	Authorization Code Flow에서 지원하는 Proof Key for Code Exchange 방식

위 application.yml을 사용하면 자동으로 구성되는 장점이 있으나, 실제 서비스를 위해서는 커스터마이징이 불가피하므로 한계가 있다.

3.2 수동 Bean 등록을 통한 Authorization Server 구성

실제 서비스 환경에서는 결국 Security Filter Chain을 서비스 요구에 맞게 커스터마이징해야한다. 따라서 본 글에서는 인가 서버의 핵심 구성 요소들을 수동 @Bean 등록하는 방식으로 구현해볼 것이다.

공식 문서에서Security Filter Chain 기반 예제를 제공하고 있어, 사실 이를 복사 • 붙여넣기만 해도 최소 구성을 빠르게 만들 수 있다.

그러나 내 글에서의 목표는 OAuth 2.1 기반으로 실제 서비스에 적용 가능한 형태로 구성 요소를 재정리 하는 것이므로 예제 설정을 다음 요구사항에 맞게 조정하려 구현하려고 한다.

구현 목표는 다음과 같다.

Authorization Server 구축
- Authorization Code Flow + PKCE
- Access Token + Refresh Token JSON으로 발급
OpenID Connect 미사용
- 기본 예제에는 OIDC 관련 설정이 포함되어 있으며, 이를 제거하고 OAuth 흐름에만 집중하여 구현할 것이다.
JPA 기반 프로젝트
- 핵심 서비스를 공식 가이드의 확장을 참고하여 구성한다.

전체 코드는 내 Github 저장소에서 확인 가능하다.

3.2.1 인가 서버 엔드포인트와 필터 체인 구조 개요

Spring Authorization Server는 내부적으로 OAuth 2.1 인가 서버 기능을 Spring Security Filter Chain 위에 구성한다.

Spring Authorization Server가 제공하는 주요 엔드포인트

구분	엔드포인트	역할
인가	`/oauth2/authorize`	Authorization Code 발급
토큰	`/oauth2/token`	Access Token / Refresh Token 발급
키	`/oauth2/jwks`	JWT 검증을 위한 JWK Set 제공
메타데이터	`/.well-known/oauth-authorization-server`	OAuth Authorization Server 메타데이터

위 엔드포인트의 목록은 AuthorizationServerSettings에 정의되어 있다.

Authorization Server 전용 필터 체인 구성
인가 서버의 전용 필터 체인은 OAuth2AuthorizationserverConfigurer를 이용하여 구성된다.

이 설정을 통해 다음 흐름이 만들어진다.

/oauth2/authorize 요청
- 인가 서버 전용 필터 체인 진입
- 인증되지 않은 경우 AuthenticationEntryPoint에 의해 /login으로 리다이렉트
/oauth2/token 요청
- 마찬가지로 인가 서버 전용 필터 체인 진입
- 클라이언트 인증 및 토큰 발급 처리

따라서 다음 구조로 처리가 된다.

HTTP 요청
  ├─ /oauth2/** 요청
  │    → Authorization Server SecurityFilterChain
  │
  └─ 그 외 요청 (/login, API 등)
       → Default SecurityFilterChain

3.2.2 Authorization Code Flow + PKCE

먼저 OAuth 2.1에서의 Authorization Code Flow는 위와 같다.

(1) 인가 요청(Authorization Request)
클라이언트는 자원 소유자의 사용자 에이전트를 인가 서버의 인가 엔드포인트로 이동시키며, 다음 정보를 포함한다.

클라이언트 식별자(client identifier)
코드 검증(code verifier)로 생성된 코드 챌린지(code challenge)
인가 요청 범위(scope)
- 본 글에서의 예제 스코프는 scope-a를 사용한다.
인가 서버가 사용자를 다시 돌려보낼 리다이렉트 URI

(2) 자원 소유자 인증(Resource Owner Authentication)
인가 서버는 자원 소유자를 인증(로그인 수행)한다.

(3) 인가 응답(Authorization Response)
자원 소유자가 동의(Consent)하면, 인가 서버는 사용자를 클라이언트의 리다이렉트 URI로 다시 이동시키면서 인가 코드(authorization code)와 state를 전달한다.

이 단계에서 코드 챌린지는 반환되지 않는다.
코드 챌린지는 인가 요청 단계에서 서버가 저장해두고, 이후 토큰 교환 시 검증에 사용한다.

(4) 토큰 요청(Token Request)
클라이언트는 토큰 엔드포인트로 요청하여 토큰 교환을 수행한다. 이때 다음을 포함한다.

인가 코드(authorization_code)
원본 코드 검증자(code_verifier)
리다이렉트 URI(redirect_uri)

(5) 토큰 응답(Token Response)
인가 서버는 다음을 검증한다.

클라리언트 인증(client authentication)
인가 코드 유효성
코드 검증자와 저장된 코드 챌린지 매칭
리다이렉트 URI 일치 여부

모든 검증이 성공하면 인가 서버는 Access Token과 Refresh Token을 반환한다.

(0) 사전 준비

현재 인가 서버에는 별도의 회원가입 기능
이 없으므로, 데모를 위해 사용자 1명과 클라이언트 1개를 사전에 등록했다.

SeedUser.java → 인증에 사용될 테스트 사용자 계정
SeedClient.java → Authorization Code Flow + PKCE를 사용하는 클라이언트 등록

실제 서비스 환경에서는 다음과 같이 대체 할 수 있다.

사용자: 회원가입 및 인증 로직을 통해 생성
클라이언트: 관리 콘솔 또는 내부 관리 API를 통해 등록

(1) 인가 요청

Authorization Code Flow + Proof Key for Code Exchange에서는, 인가 요청 이전에 클라이언트가 PKCE 관련 값을 미리 생성해야 한다.

PKCE 값 생성
macOS 기준으로 다음 명령어를 사용하여 필요한 값들을 생성할 수 있다.

code_verifier=$(openssl rand -base64 32 | tr '+/' '-_' | tr -d '=')
code_challenge=$(printf '%s' "$code_verifier" | openssl dgst -sha256 -binary | openssl base64 | tr '+/' '-_' | tr -d '=')
state=$(openssl rand -base64 16 | tr '+/' '-_' | tr -d '=')

printf 'code_verifier=%s\ncode_challenge=%s\nstate=%s\n' \
"$code_verifier" "$code_challenge" "$state"

인가 요청 파라미터
클라이언트는 다음 정보를 포함하여 인가 엔드포인트(/oauth2/authorize)로 요청한다.

{
  "response_type": "code",
  "client_id": "client-a",
  "redirect_uri": "http://127.0.0.1:8080/authorized(Require URL Encoding)",
  "scope": "scope-a",
  "state": "random-state-123",
  "code_challenge": "BASE64URL(SHA256(code_verifier))",
  "code_challenge_method": "S256"
}

인가 요청 URL 예시

GET http://localhost:9000/oauth2/authorize
  ?response_type=code
  &client_id=client-a
  &redirect_uri=http%3A%2F%2F127.0.0.1%3A8080%2Fauthorized
  &scope=scope-a
  &state=Ou53KVMRtdSubCpiXHNmhw
  &code_challenge=...
  &code_challenge_method=S256

(2) 자원 소유자 인증

브라우저에서 /oauth2/authorize에 요청이 들어오면, 인가 서버는 사용자가 인증 상태인지 아닌지를 판단한다. 인증이 안된 사용자의 경우에는 로그인 페이지로 이동하며, 인증 완료된 사용자는 동의 화면 → 인가 코드 발급으로 이루어진다.

단계	요청	상태	설명
1	`GET /oauth2/authorize`	(처리 중)	미인증 상태
2	내부 인증 판단	—	`AnonymousAuthenticationToken`
3	AuthenticationEntryPoint 호출	—	인증 필요로 판단
4	`/login` 리다이렉트	302 Found	`LoginUrlAuthenticationEntryPoint`
5	`GET /login`	200 OK	Spring Security 기본 로그인 페이지 렌더링

인증되지 않은 사용자는 /login으로 이동
인증이 완료되면, 다시 인가 요청 흐름으로 복귀
이미 로그인된 상태라면 바로 동의 화면으로 진행된다.

인증 수행
현재 구현으로는 인증이 필요한 경우에는 Spring Security에 이미 정의되어 있는 인증 페이지로 리다이렉트 한다.

로그인 페이지에서 SeedUser.java에서 설정해둔 인증 정보를 입력하여 인증을 수행한다.

username: user
password: password

동의 화면
동의 화면은 Spring Authorization Server 라이브러리 내의 DefaultConsentPage에 정의되어 있는 동의 화면이 기본으로 제공된다.

사용자 인증 완료 시, 다음 화면과 로그를 확인할 수 있다.

DefaultConsentPage HTML로 기본 동의 화면이 구현되어 있는 것을 확인할 수 있다.

로그에서도 사용자 인증 후 동의 화면으로 리다이렉트를 수행하는 것을 확인할 수 있다.

(3) 인가 응답

사용자가 동의하면, 인가 서버는 클라이언트의 리다이렉트 URI로 이동시키며, 인가 코드(authorization_code)와 state를 전달한다.

사용자 동의 후, 서버 로그

리다이렉트 URI 내부에 code와 state가 다음과 같이 구성되어 있으며, HTTP 응답 상태 코드는 302 Found이다.

http://127.0.0.1:8080/authorized

?code=dSCLUogPUDpCKsW96N4L9IHEexPNzqvB4sUQqPLWQE98UY4c_pKw_2RyjVKD2jZt_wlJ_6fQNEUiyaRRje4i6bZZLExxnwE0bBpefqqpsu21G6O0QUTCUyxbGTSCV1cn

&state=Ou53KVMRtdSubCpiXHNmhw

state는 CSRF 방지용 값으로 클라이언트는 이 값을 통해서 위조 및 중간자 공격이 있었는지 검증한다.

그리고 이 응답의 성공은 302이다.

(4) 토큰 요청

인가 서버의 토큰 요청의 엔드포인트로 다음 정보를 포함하여 요청한다.

POST /oauth2/token

Content-Type: application/x-www-form-urlencoede
Authorization: Basic Y2xpZW50LWE6c2VjcmV0(client-a:secret을 인코딩한 값)

grant_type = authorizaton code
& code = 발급 받은 코드 입력
&redirect_uri = http%3A%2F%2F127.0.0.1%3A8080%2Fauthorized
&code_verifier = 원본 code_verifier

(5) 토큰 응답

인가 서버는 다음을 검증하고 로그에서도 확인할 수 있다.

클라이언트 인증
인가 코드 유효성
code_verifier ↔ code_challenge 매칭
리다이렉트 URI 일치 여부

모든 검증이 성공하면, 인가 서버는 토큰 정보를 다음과 같이 JSON으로 반환한다.

{
    "access_token": "eyJraWQiOiI1NTViNTUxZi00YzExLTQxMmMtOTIyNC01MDY1NzhkZjAxOTQiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyIiwiYXVkIjoiY2xpZW50LWEiLCJuYmYiOjE3NjkwNDU1MTUsInNjb3BlIjpbInNjb3BlLWEiXSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo5MDAwIiwiZXhwIjoxNzY5MDQ3MzE1LCJpYXQiOjE3NjkwNDU1MTUsImp0aSI6ImY0ZjNiZTc2LTBjYzEtNDY1Zi1iN2I0LWNlYjI1MzRmNmE1YyJ9.VyIILO-meMU0wAkNJixc8bhWilldNRcd45Q_uopnafsTz41uztslGY_Ir_hGqqV5F_hFTHWQ8aCHKtJiIsBVJOZDceAGC5U0m-EetwvJjYT6GY4nfhYZxDPWi3vX3rdxsvskAlZV9veHcRvo5ffcLl61Pi7W5UjeSsnl_8Yhc4RUbkOGOGCcnySSvc1rnLTWXEcctgHucLvEzeiiR169Sd5sTdwkBWPcxi5cSCWchfCi-1rs7RV6iVz0H_EbMTg6I5Hg96i9fm5WCBfEZpOYb4enu9Cz3suhfjCPqFkTQ6q3Fx4yNH_0OwISX4Dmo4XDWP3LAtUNSDebkA8SjtL4NA",
    "refresh_token": "kZ6vQJTZpuS1lZvwIVBfswq3TvpG17xzJuVeYFauA5x0RBRFKB-7Fm1-893avhnvtQUsv1o6Yo7vlRapox0gNTTtyPMANxK9Vrcf2V6vvil0SEVEjyxJcLtmtLQwX2qh",
    "scope": "scope-a",
    "token_type": "Bearer",
    "expires_in": 1799
}

이후 클라이언트는 발급 받은 Access Token을 사용하여 리소스 서버의 보호된 자원에 접근하게 된다.

4. 인가 서버 데이터베이스 구조

거의 다 왔다..

Security Filter 부터 Authorization Code Flow + PKCE까지 인가 서버의 전 과정을 정리해보았다.

다음으로는 해당 데이터들이 어떤 구조를 가지고 있는지 어떤 순서대로 저장이 되는지를 다뤄보고자 한다.
아래는 OAuth 2.1에 해당되는 DB 구조이다.

데모 프로젝트에서는 다음과 같이 데이터가 입력된다.

사용자 & 클라이언트 사전 등록
- SeedUser와 SeedClient를 통해서 초기 사용자와 클라이언트가 users와 oauth2_registered_client에 저장된다.
인증과 클라이언트 검증
- 사용자 인증은 users테이블을 기준으로 수행된다.
- 클라이언트 검증은 인가 요청 시 전달된 client_id로 oauth2_registered_client에 저장된 클라이언트 정보와 비교하여 검증한다.
사용자 동의
- 사용자가 동의하면, 해당 동의 정보는 oauth2_authorization_consent 테이블에 저장된다.
- 이미 동의한 이력이 있는 경우, 동의 화면은 생략된다.
토큰 발급 및 인가 상태 저장
- 동의가 완료디면 클라이언트는 /oauth2/token 엔드포인트로 토큰 교환을 요청한다.
- 인가 서버는 다시 한 번 클라이언트 정보를 검증한 뒤 토큰을 발급한다.
- 이 때 다음 정보들이 oauth2_authorization에 저장된다.
  - Authorization Code
  - Access Token
  - Refresh Token
  - PKCE 관련 정보
  - 사용자 및 클라이언트 정보

oauth2_authorization 테이블은 Authorization Code Flow 전체 상태를 하나 관리하는 핵심 테이블이다.

마치며,,

우선, 본글에서 다룬 데모 프로젝트 전체 코드는 아래 GitHub 저장소에서 확인할 수 있다.
OAuth 2.1 인가 서버를 처음부터 끝까지 직접 구성해보고 싶은 경우 참고하면 도움이 될 것 같다.

🔗 데모 코드: https://github.com/Gumraze-git/devlog-demo-spring-boot-oauth2-1
Star도 하나씩 부탁드립니다!

글을 작성하기 전, 기존 목적은 각 설정과 코드를 하나씩 씹고 뜯고 맛보려고 했지만,,
실제로는 Spring Authorization Server가
이미 OAuth 2.1 인가 서버에 필요한 대부분의 구성 요소를 잘 제공하고 있어, 라이브러리 내의 코드 일부만 살펴보았다.

그래서 본 글에서는 구현 세부 코드 자체 보다는,

각 컴포넌트가 어떤 책임을 가지고 있는지
Authorization Code Flow + PKCE가 어떤 순서로 실제 동작하는지
그 과정에서 필터 체인과 데이터가 어떻게 연결되는지
를 중심으로 다루었다.

OAuth 2.1에 아쉬운점

서론에서 실제 프로젝트에 적용할 수 있는 수준,
OAuth 2.1 공식 문서를 기반으로 데모 프로젝트를 구현하는 것을 목표라고 했다.

그러나, 사실 OAuth 2.1 공식 문서들을 기반으로 구현했음에도 불구하고 실제 프로젝트에서는 몇 가지 고려해야하는 부분이 여전히 존재한다.

토큰을 JSON으로 반환
현재 데모 프로젝트는 Access/Refresh Token을 JSON 형식으로 응답하고 있다.

공식 문서에는 클라이언트가 서버인지 SPA인지 등을 고려하지 않고 있다.
따라서, 서버 간 통신 환경에서는 큰 문제가 없지만, SPA 기반 프로젝트인 경우에는 다음 문제가 발생한다.

브라우저에 토큰 응답이 직접 노출됨.
OAuth 2.1은 브라우저를 신뢰하지 않는 전제 조건이 위반됨.

따라서 이러한 경우에는 일반적으로 다음 전략으로 해결해야한다.

Backend For Frontend(BFF) 구조
HttpOnly, Secure Cookie 기반 토큰 전달

나와 같은 취준생이 개인 프로젝트를 구현한다고 할 때, 풀스택 개발자가 아니면 BFF같은 것을 구현하는 것은 소요가 너무 커서 굳이? 싶다.

따라서 Cookie로 토큰을 전달하는 방식이 현재 나와 같은 상황에서는 맞다고 생각한다.

먼저 기본적으로 위 구조를 이해한 다음 실제 적용 시에는 Cookie를 사용하는 것은 직접 구현해 보면 될 거 같다.
생각보다 어렵지 않으며, 여기서는 OAuth 2.1 문서에 기반하여 다루기 때문에 Cookie 사용 방식은 다루지 않는다.

아무래도 OAuth 2.1과 같은 명세는 모든 실무 환경을 반영하기 어렵다는 한계가 이와 같이 나타나는 것 같다.

그래서 지금까지 OAuth 2.0 부터 2.1까지 시리즈로 알아보았다.
이제 다루고 싶은 내용은 OAuth 관련된 내용과 추가적으로 기본기에 대한 내용이다.

HTTP/HTTPS
OIDC
JWT의 stateless, stateful
RESTful과 문서화(Swagger)
Docker
AWS EC2
Lombok
Spring과 Spring Boot의 배경
etc...

개발자 취업 준비하면서 정말 공부해야할게 많다고 느낀다. 동시에 모든 것을 알 수 있는 것도 아니기 때문에 하나라도 제대로 아는 것이 더 중요하다고 느끼게 되는 것 같다.

진짜 진짜 마지막으로는,
블로그 글은 언제나 참고 자료로 활용하되
가능하다면 항상 공식 문서를 직접 읽어보는 것을 강력히 권장한다.

감사합니다. ㅎ

참고문헌

Spring Blog – Spring Authorization Server moving to Spring Security 7.0
https://spring.io/blog/2025/09/11/spring-authorization-server-moving-to-spring-security-7-0
Spring Security Reference Documentation – Migrating to Spring Security 7.0
https://docs.spring.io/spring-security/reference/migration/index.html
Spring Security Reference Documentation – OAuth 2.0 Authorization Server
https://docs.spring.io/spring-security/reference/servlet/oauth2/authorization-server/index.html
Spring Authorization Server Reference Documentation
https://docs.spring.io/spring-authorization-server/reference/
RFC 8414 – OAuth 2.0 Authorization Server Metadata
https://datatracker.ietf.org/doc/html/rfc8414
RFC 6749 – The OAuth 2.0 Authorization Framework
https://datatracker.ietf.org/doc/html/rfc6749
RFC 7636 – Proof Key for Code Exchange by OAuth Public Clients
https://datatracker.ietf.org/doc/html/rfc7636
OAuth 2.1 Draft – OAuth 2.1 Authorization Framework (Draft)
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1
IETF OAuth Working Group
https://datatracker.ietf.org/wg/oauth/documents/
OpenID Foundation – OpenID Connect Core 1.0
https://openid.net/specs/openid-connect-core-1_0.html

Daehwan Kim

개발 참 즐겁습니다.

이전 포스트

[OAuth] Spring Authorization Server로 인가 서버 직접 구축하기

OAuth

1. 서론

2. 인가 서버의 의존성 구성

2.1 Spring Authorization Server 구성

2.2 의존성 설정

3. 인가 서버 구현

3.1 `application.yml` 기반 최소 구성 방식

(1) `application.yml` 자동 구성 방식의 특징

3.2 수동 Bean 등록을 통한 Authorization Server 구성

3.2.1 인가 서버 엔드포인트와 필터 체인 구조 개요

3.2.2 Authorization Code Flow + PKCE

(0) 사전 준비

(1) 인가 요청

(2) 자원 소유자 인증

(3) 인가 응답

(4) 토큰 요청

(5) 토큰 응답

4. 인가 서버 데이터베이스 구조

마치며,,

OAuth 2.1에 아쉬운점

참고문헌

[OAuth] OAuth 2.1의 등장

0개의 댓글

[OAuth] Spring Authorization Server로 인가 서버 직접 구축하기

OAuth

1. 서론

2. 인가 서버의 의존성 구성

2.1 Spring Authorization Server 구성

2.2 의존성 설정

3. 인가 서버 구현

3.1 application.yml 기반 최소 구성 방식

(1) application.yml 자동 구성 방식의 특징

3.2 수동 Bean 등록을 통한 Authorization Server 구성

3.2.1 인가 서버 엔드포인트와 필터 체인 구조 개요

3.2.2 Authorization Code Flow + PKCE

(0) 사전 준비

(1) 인가 요청

(2) 자원 소유자 인증

(3) 인가 응답

(4) 토큰 요청

(5) 토큰 응답

4. 인가 서버 데이터베이스 구조

마치며,,

OAuth 2.1에 아쉬운점

참고문헌

[OAuth] OAuth 2.1의 등장

0개의 댓글

3.1 `application.yml` 기반 최소 구성 방식

(1) `application.yml` 자동 구성 방식의 특징