OAuth 2.0 OBO 플로우가 필요한 이유
현대 엔터프라이즈 애플리케이션은 단일 서비스로 동작하는 경우가 드물다. 사용자는 웹 또는 모바일 앱을 통해 인증하고, Java 백엔드 API를 호출하며, 그 백엔드는 다시 내부 마이크로서비스나 외부 서드파티 API를 호출하는 구조가 일반적이다. 이처럼 다중 서비스가 연계된 아키텍처에서는 인증 컨텍스트를 어떻게 전파할 것인가가 핵심 설계 문제로 떠오른다.
가장 단순한 접근은 백엔드 애플리케이션 자체의 자격증명(Client Credentials)으로 다운스트림 서비스를 호출하는 것이다. 하지만 이 방식은 다운스트림 서비스 입장에서 최초 요청을 시작한 사용자가 누구인지 알 수 없다는 치명적인 한계를 가진다. 서비스 간 통신에서 사용자의 권한 범위를 그대로 유지해야 하는 경우, 애플리케이션 identity만으로는 세밀한 인가(Authorization) 처리가 불가능하다.
OBO 플로우의 개념적 구조
OAuth 2.0 On-Behalf-Of(OBO) 플로우는 이 문제를 해결하기 위해 설계된 토큰 교환 메커니즘이다. 핵심 아이디어는 간단하다. 백엔드 API가 사용자로부터 받은 액세스 토큰을 Authorization Server에 제출하고, 다운스트림 서비스를 호출하기 위한 새로운 액세스 토큰으로 교환받는 것이다. 이 과정에서 원래 사용자의 identity와 권한이 새 토큰에 그대로 반영된다.
[사용자] → (AccessToken A) → [Java 백엔드 API]
↓ OBO 토큰 교환 요청
[Authorization Server]
↓ AccessToken B (사용자 컨텍스트 유지)
[Java 백엔드 API] → (AccessToken B) → [다운스트림 서비스]
이 흐름에서 주목할 점은 다운스트림 서비스가 수신하는 토큰이 서비스 계정의 토큰이 아니라 사용자 컨텍스트를 포함한 토큰이라는 것이다. 덕분에 다운스트림 서비스는 요청을 시작한 사용자의 역할(Role)이나 권한 범위(Scope)를 기반으로 정밀한 인가 로직을 수행할 수 있다.
실무에서 왜 중요한가
4년차 이상의 백엔드 개발자라면 마이크로서비스 아키텍처에서 서비스 간 인가 처리의 복잡성을 실감했을 것이다. OBO 플로우 없이 설계된 시스템에서는 흔히 다음과 같은 문제가 발생한다.
- 권한 과잉 부여: 서비스 계정에 모든 권한을 부여해 보안 경계가 흐려짐
- 사용자 컨텍스트 유실: 감사 로그(Audit Log)에서 실제 사용자 추적이 어려워짐
- 커스텀 헤더 남용: 사용자 정보를 별도 헤더로 전달하는 비표준 방식이 확산되어 유지보수 비용 증가
OBO 플로우를 적용하면 이러한 문제를 OAuth 2.0 표준 메커니즘 안에서 해결할 수 있다. 특히 Azure AD, Okta 등 엔터프라이즈 환경에서 널리 사용되는 IdP들이 OBO 플로우를 공식 지원하므로, Java 생태계(Spring Security, MSAL4J 등)와의 연동도 비교적 명확한 패턴으로 구현 가능하다.
정리
- OBO 플로우는 다중 서비스 연계 구조에서 사용자 identity와 권한을 다운스트림까지 안전하게 전파하기 위한 OAuth 2.0 표준 메커니즘이다.
- 애플리케이션 자체 자격증명(Client Credentials)만으로는 세밀한 사용자 기반 인가 처리가 불가능하며, 이 간극을 OBO가 채운다.
- 마이크로서비스 간 보안 설계 시 비표준 사용자 컨텍스트 전달 방식 대신 OBO 플로우를 표준 대안으로 검토할 필요가 있다.