OAuth란 무엇인가?
Source: Hacker News
Background
최근 X(구 Twitter)에서 “Matt Levine 스타일”로 OAuth가 어떻게 동작하는지, 그리고 왜 그렇게 설계되었는지에 대한 설명을 달라는 질문이 있었습니다.
“나는 절실히 Matt Levine 스타일의 OAuth 작동 방식 설명이 필요해. 이곳에 이르게 된 역사적 요구 사항들의 연쇄는 무엇이었을까?” – geoffreylitt
질문자는 다양한 흐름에 대한 저수준 튜토리얼을 원한 것이 아니라, 설계를 형성한 동기 부여된 사용 사례를 이해하고 싶어했습니다.
Sign‑In Use‑Case (OpenID Connect)
OAuth를 실제로 보는 가장 쉬운 방법은 인증을 제공하도록 OAuth 위에 구축된 OpenID Connect(OIDC)입니다. OIDC는 “매직‑링크” 로그인이라고 생각할 수 있습니다:
- 서버가 사용자만 접근할 수 있는 위치(예: 이메일이나 모바일 앱)로 비밀 코드를 보냅니다.
- 사용자는 그 비밀 코드를 서버에 다시 제시함으로써 해당 위치에 접근할 수 있음을 증명합니다.
비밀 코드가 확인되면 사용자는 인증된 것입니다. 어휘, UX 세부 사항, 추가 보안 검증 등 주변 사양들은 이 핵심 아이디어 위에 얹힌 층입니다.
Why a New Standard Was Needed
2006년 말, 트위터에서 일하던 팀은 트위터가 중앙 집중식 아이덴티티 제공자가 되지 않도록 OpenID 1.0을 지원하고 싶었습니다. 하지만 기존 OpenID 흐름은 비밀번호를 요구했으며, 이는 데스크톱 클라이언트나 신생 모바일 앱에서는 작동하지 않았습니다.
다른 사이트들은 (Flickr, AWS, Delicious 등) 임시방편적인 해결책을 가지고 있었지만 보안이 취약하고 맞춤형이었습니다. 필요했던 것은 사용자의 비밀번호를 노출하지 않고 제3자 애플리케이션이 사용자를 대신해 동작할 수 있는 표준적이고 안전한 방법이었습니다.
이 격차가 OAuth라는 위임‑인증 프로토콜의 탄생으로 이어졌습니다.
Core Idea of OAuth
본질적으로 OAuth는 두 단계 과정입니다:
- 동의 및 비밀 배포 – 사용자(리소스 소유자)가 동의를 하고, 인증 서버가 다중 사용 비밀(액세스 토큰)을 신뢰할 수 있는 위임자(클라이언트 애플리케이션)에게 발급합니다.
- 토큰 사용 – 위임자는 그 비밀을 리소스 서버에 제시하여 사용자를 대신해 작업을 수행합니다.
그 외의 요소들—리프레시 토큰, 스코프, PKCE, 토큰 인트로스펙션 등—은 기본 패턴을 안전하고 상호 운용 가능하게 만들기 위한 부가적인 메커니즘일 뿐입니다.
Historical Context
- 2006‑2007: 제3자 클라이언트를 위한 비밀번호 없는 로그인 필요.
- 2007: 최초 OAuth 초안 작성.
- 2009: OAuth 1.0 발표(서명 기반).
- 2012: OAuth 2.0 출시, 흐름을 단순화(베어러 토큰)하고 확장성을 추가.
- 2014‑현재: OpenID Connect가 OAuth 2.0 위에 구축되어 표준화된 인증 제공.
이 진화는 보안, 사용성, 확장성 사이의 균형을 반영합니다. 표준화 기구는 실제 위협과 개발자 경험을 다루기 위해 “소음”(예: 토큰 폐기, 동적 클라이언트 등록) 등을 추가했습니다.
Practical Takeaway
OAuth를 구현할 때는 다음 질문에 답하는 것이 출발점입니다:
- 무엇을 달성하려는가? (예: 모바일 앱이 사용자를 대신해 게시물을 올리게 하려는 경우)
- 왜 위임이 필요한가? (예: 앱이 사용자의 비밀번호를 알 필요가 없기 때문)
목표가 명확해지면 OAuth 흐름(인증 코드, 암시적, 클라이언트 자격 증명 등)은 그 제약을 만족시키는 일련의 기계적 단계가 됩니다.
Conclusion
OAuth 설계는 단순한 문제에서 출발했습니다: 사용자가 자격 증명을 공유하지 않고 제3자 애플리케이션에 제한된 접근 권한을 안전하게 부여하려면 어떻게 해야 하는가? 나머지 사양은 수십 년에 걸친 점진적 개선, 보안 강화, 합의 형성의 결과물입니다.
그 핵심 동기를 이해하면 프로토콜이 덜 신비롭게 보이며, 구현과 사용이 훨씬 쉬워집니다.