AI Agent의 OAuth Token 관리 - 2 or 3 Legged OAuth (2LO, 3LO)

Agent를 내 클라우드 리소스 접근을 허용하도록 OAuth token을 맡기자니 뭔가 깨름칙하다. 예전부터 어떤 프로그램에 내 OAuth Token을 embed하는 것은 아무 문제 없이 여겼지만 AI Agent는 자율성이 높아지면서 어떤 결과를 초래할지 몰라 쉽게 embedding 하기 어렵다. Token을 위임하냐 안하냐에 따라서 구조가 2LO/3LO (2,3 Legged Oauth)라 부르는데 Term에 대한 정의와 token을 어떻게 관리해야 하는지에 대한 가이드라인 동향을 알아본다.

---

1. leg = 참여 당사자

3LO와 2LO는 인증에 참여하는 당사자(party)의 수를 가리키는 관습적인 표현에 가깝다.

OAuth 흐름의 "leg"는 인증에 참여하는 주체(party) 하나를 의미한다. 다리 개수가 곧 참여 주체 수.

3LO에 등장하는 세 주체:

1. User       (Resource Owner) — 데이터의 실제 주인
2. Client     (Application)    — 데이터에 접근하려는 앱
3. Auth Server(+ Resource Server) — 토큰 발급 / 데이터 보관

 

2LO에서는 User가 빠지고 Client ↔ Auth Server 두 주체만 남는다. 사람이 끼어들지 않으니 동의 화면(consent screen)도 없다.

 

2. 3LO와 2LO 차이

구분	3LO (Three-Legged)	2LO (Two-Legged)
참여 주체	User + Client + Server	Client + Server
누구의 권한	사용자를 대신해 접근	앱 자신의 권한으로 접근
동의 화면	있음 (브라우저 redirect)	없음
대표 Grant	Authorization Code	Client Credentials
사용 맥락	"내 구글 캘린더 읽게 허용"	서버↔서버 batch, 내부 API
토큰이 표현하는 것	위임된 사용자 권한	앱 고유 권한

 

핵심은 누구의 권한으로 접근하느냐다. 3LO는 사용자가 자신의 권한 일부를 앱에 위임(delegation)하는 구조고, 2LO는 앱이 처음부터 자기 권한으로 움직인다.

 

2LO	3LO
2LO Sequence diagram	3LO Sequence diagram

 

3LO는 User가 흐름 안에 들어와 직접 "허용"을 누르고, 2LO는 Client가 자격증명만으로 토큰을 바로 받는다.

 

 

3. 왜 Agent에서는 3LO를 추천하는가

Agent(자율적으로 도구를 호출하는 LLM 시스템)가 외부 서비스에 접근할 때, 동의 화면도 없고 토큰 한 번 embed하면 끝이니까 편하지만 그럼에도 3LO를 권하는 이유는:

 

1) 권한 범위가 사용자 단위로 제한됨

3LO 토큰은 "이 사용자가 허용한 범위(scope)"만 담는다. Agent가 오작동하거나 탈취당해도 영향 범위가 해당 사용자의 위임 권한으로 묶인다. 반면 2LO 토큰은 앱 전체 권한을 들고 있어, 사고 시 폭발 반경(blast radius)이 훨씬 크다.

 

2) 감사(audit)와 추적이 명확

3LO는 "어떤 사용자를 대신해" 한 동작인지 토큰에 남는다. Agent가 무엇을, 누구 권한으로 했는지 로그에서 분리해 추적 가능. 2LO는 모든 동작이 "앱"이라는 하나의 주체로 뭉뚱그려져 누구를 위한 작업이었는지 흐려진다.

 

3) 명시적 동의(consent)가 사용자에게 통제권을 줌

3LO는 사용자가 직접 scope를 보고 허용/거부하고, 나중에 access를 취소(revoke)할 수 있다. Agent가 사용자 데이터를 다룰 때 이 통제권은 신뢰의 핵심. 2LO에는 사용자가 끼어들 지점 자체가 없다.

 

4) 최소 권한 원칙(least privilege)에 부합

Agent는 보통 특정 사용자의 특정 작업을 대행한다. 그렇다면 그 사용자의, 그 작업에 필요한 권한만 받는 게 맞다. 3LO의 위임 모델이 이 구조에 자연스럽게 들어맞는다.

 

 

AWS와 Google Cloud는 사용자별 외부 리소스에 접근하는 agentic workflow에는 3-legged OAuth를 사용하도록 안내한다.

• AWS: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-terminology.html
• Google Cloud: https://docs.cloud.google.com/iam/docs/auth-with-3lo

AWS는 personal access 용도에서 managed 3LO를 권장 인증 방식으로 명시하지만 2LO는 사용자 위임이 필요 없는 machine-to-machine 또는 application-level access에 적합하기 때문에 2LO 스타일 접근도 정당한 패턴으로 본다. IAM Role, 서비스 계정, machine-to-machine 인증처럼 사람이 끼어들지 않는 것이 정상인 맥락이 많기 때문.

- 서버 간 내부 API 호출
- 백그라운드 batch / cron job
- 인프라 자동화 (Agent가 사용자가 아닌 시스템 자원을 다룸)

 

즉, Agent가 특정 사용자를 대행한다면 3LO가, 시스템 자체로 동작한다면(사용자 데이터에 접근하지 않는 인프라 작업) 2LO가 맞는 선택. 둘 중 하나가 절대선이 아니라, Agent가 누구의 권한으로 움직이는가가 기준이 된다.

 

4. 정리

3LO = User + Client + Server   → 사용자 권한 위임, 동의 화면 O
2LO = Client + Server          → 앱 자신의 권한, 동의 화면 X

 

사용자 데이터를 다루는 Agent라면 권한 제한·감사·통제권 측면에서 3LO가 기본. 사람이 개입할 필요 없는 시스템 작업이라면 AWS처럼 2LO도 정당한 선택. 판단 기준은 항상 "이 토큰이 누구의 권한을 표현하는가"다. Enterprise 같은 multi-user 환경에서는 3LO, User가 나 하나거나 machine-to-machine 상황에는 2LO를 사용하는 것이 옳바른 방향이 아닐까 생각한다.