[NHN FORWARD 2021] Spring Security 5 OAuth 총정리: 클라부터 서버까지

NHN Cloud·nhn-forward-2021 ·2021년·

#authentication#oauth2#java#sso#spring-security#authorization

AI 요약

고객 SSO와 연동하며 OAuth client와 server를 모두 구현해야 했던 관점에서 Spring Security 5의 OAuth 2.0 지원을 정리한다. 분리돼 혼란스럽던 이전 생태계가 왜 하나의 API로 통합됐는지 역사와 함께, production에서 실제로 필요한 설정 지점을 짚는다.

핵심 포인트

Resource Owner·Client·Resource Server·Authorization Server 네 역할과 authorization code→token 교환→검증 흐름을 사진첩 사례로 설명하고, formLogin처럼 oauth2Login 한 줄에서 시작하는 통합 설정을 제시
과거 Spring Security OAuth·Spring Social·Boot @EnableOAuth2Sso로 흩어졌던 설정이 Security 5에서 Client·Resource Server 통합 재구현으로 정리되고, Authorization Server는 community 요구로 별도 project로 부활
Client는 in-memory authorized client service가 사용자 증가 시 OOM·다중 서버 인증 소실을 유발하므로 JDBC나 앱 data store로 교체. Authorization Server는 최우선 SecurityFilterChain + RegisteredClientRepository + JWKSource 구성이 필요하고 당시 0.2.0엔 UserInfo endpoint를 직접 구현

왜 읽나Spring Security 5로 OAuth client·server를 production에 올려야 하는 백엔드 개발자에게 protocol 역할·migration 배경·설정 함정을 아우르는 안내서.

챕터별 상세

010:11 – 3:31

Spring Security 5가 OAuth를 통합한 배경

Dooray는 고객 SSO에 접속하는 OAuth Client가 되기도 하고 외부 client에 token을 주는 server가 되기도 한다. Spring Security 5는 formLogin처럼 oauth2Login 한 줄에서 시작하는 일관된 설정을 제공하지만 이전 생태계는 그렇지 않았다. 발표는 Client·Resource Server·Authorization Server를 모두 구현하는 데 필요한 protocol 역할과 migration history, production 설정을 함께 다룬다.

Spring Security 4까지 OAuth는 별도 subproject였고 1.0·2.0과 모든 role을 지원했다. 사진첩 사례로 사용자인 Resource Owner, 사진을 제공하는 Resource Server, 이를 쓰는 Client, 동의를 검증하는 Authorization Server를 구분한다. Client가 authorization grant를 받아 token으로 교환하고 Resource Server가 token을 검증한 뒤 제한 resource를 내주는 전체 흐름을 설명한다.

과거에는 여러 annotation·filter·OAuth2RestTemplate을 직접 조합하고 확장 point가 부족해 class를 억지로 교체해야 했다. OAuth가 authorization protocol인데 login에 쓰려다 먼저 인증하라는 오류가 나는 혼란도 Boot의 @EnableOAuth2Sso와 Spring Social을 낳았다. Spring Security 5가 Client와 Resource Server를 통합 재구현하고, community 요구로 Authorization Server를 별도 project로 되살린 과정을 정리한다.

Spring Boot는 Google·GitHub 같은 provider는 client ID와 secret만으로, custom provider도 registration과 endpoint 정보만으로 client를 구성한다. 하지만 access·refresh token을 가진 authorized client의 기본 service가 in-memory라 사용자가 늘면 OOM이 나고 다중 server에서 인증이 사라질 수 있다. JDBC 구현이나 application의 data store로 교체하고 authorization·redirect·token·userInfo endpoint별 확장 point를 사용한다.

별도 spring-authorization-server 의존성을 추가하고 전용 SecurityFilterChain을 가장 높은 우선순위로 등록해 protocol endpoint만 처리하게 한다. Client 정보를 저장하는 RegisteredClientRepository와 JWT를 서명하고 public key를 제공할 JWKSource를 구성하며, 나머지 request에는 별도 default chain을 둔다. 당시 0.2.0에서 빠진 UserInfo endpoint는 직접 구현해야 했고 후속 release에 포함될 상태라는 제약도 짚는다.