OAuth 2.0 인증 흐름 4가지, 실무에서 살아남은 한 가지

최종 수정일: 2026년 08월 03일

OAuth 2.0은 사용자의 비밀번호를 넘기지 않고 앱에 제한된 접근 권한만 위임하는 표준입니다. 권한 부여 코드, 클라이언트 자격 증명 등 네 가지 흐름 중 실무에서는 PKCE를 적용한 권한 부여 코드 흐름이 사실상 기본값입니다. 2025년 1월 발표된 RFC 9700은 공개 클라이언트의 PKCE 사용을 의무화하고, 비밀번호 자격 증명 흐름은 금지했습니다.

잊히지 않는 아찔한 경험이 하나 있었는데요. 어떤 앱이 제 사진첩에 접근하겠다며 비밀번호를 요구하더군요. 그때는 ‘뭐 별일 있겠어?’ 하는 생각에, 의심 없이 비밀번호를 입력했던 기억이 생생합니다. 지금 돌이켜보면 얼마나 위험한 일이었는지 아찔하기만 합니다.

그런데 요즘은 그런 걱정 없이 ‘구글 계정으로 로그인’ 버튼 하나만 누르면 여러 서비스를 편리하게 이용할 수 있지 않습니까? 편리함과 안전함을 같이 잡는 기술, 그 뒤에 OAuth 2.0이 숨어 있습니다.

이 글에서는 OAuth 2.0이 무엇인지, 어떻게 작동하는지, 그리고 최신 표준을 통해 얼마나 안전하게 활용되는지까지 최대한 쉽게 정리해 보겠습니다.

OAuth 2.0은 어떻게 작동할까요?

제가 처음 OAuth 2.0을 접했을 때, 이 기술이 단순히 ‘편리한 로그인’이 아니라는 점에서 꽤 놀랐습니다. 비밀번호를 직접 넘기지 않고도, 특정 앱이 필요한 정보에만 ‘잠깐’ 접근하도록 허락해주는 구조였기 때문입니다.

예를 들어 GitHub에 저장된 제 코드를 어떤 배포 서비스가 자동으로 가져와 빌드해야 한다고 해보겠습니다. 이때 그 서비스에 제 GitHub 아이디와 비밀번호를 알려줄 필요가 없습니다. 대신 GitHub이 “이 서비스가 당신의 코드를 읽고 쓸 권한을 원합니다. 허락하시겠습니까?”라고 묻고, 제가 승인하면 GitHub이 특별한 ‘허락증’을 발급해 줍니다. 이 허락증이 바로 ‘제한된 접근 권한’이고, 핵심은 사용자(저)의 비밀번호를 노출하지 않은 채 권한을 위임한다는 데 있습니다.

OAuth 2.0은 2012년 10월 정식 표준(통신 규칙)으로 자리 잡았습니다. OAuth 1.0보다 훨씬 유연하고 편리해졌고요. 실무에서 써보면 초기 설정은 조금 번거롭지만, 나중에 보안 이슈로 골치 아플 일이 확실히 줄어듭니다. 그래서 저는 가능하면 OAuth 2.0을 권장하는 편입니다.

이 프로토콜은 ‘허락증을 받는 방법’을 크게 네 가지로 구분해 정의합니다. 그중에서도 ‘권한 부여 코드(Authorization Code)’ 방식이 가장 안전해서 서버 기반 웹 서비스에서 주로 채택되는 경향이 있습니다.

OAuth 2.0은 공공·금융을 포함한 다양한 분야에서 표준으로 자리 잡았습니다. 특히 권한 부여 코드(authorization code)가 공격자에게 탈취되는 것을 막으려면 PKCE(Proof Key for Code Exchange)를 함께 써야 하며, 이는 IETF가 RFC 9700에서 공식적으로 요구하는 사항입니다. 예전에 API 연동 프로젝트를 맡았을 때, PKCE 적용 여부를 확인하느라 테스트를 여러 번 반복했던 기억이 남아 있습니다.

OAuth 2.0에서 또 하나 중요한 개념이 ‘스코프(scope)’입니다. “이 앱은 이메일 주소만 볼 수 있습니다”처럼, 앱이 요청하는 권한 범위를 명확하게 정해주는 장치입니다. 사용자는 앱이 내 정보를 전부 가져가는 게 아니라, 필요한 범위에서만 접근하도록 통제할 수 있습니다.

예를 들어 제가 Google 포토 API로 사진을 특정 웹사이트에 게시하는 기능을 만들 때, ‘사진 읽기’ 스코프만 요청하고 ‘사진 삭제’ 스코프는 요청하지 않았습니다. 이런 식으로 권한을 최소화하면 사용자 정보는 더 안전해집니다.

물론 공격 위험이 완전히 사라지는 것은 아닙니다. OAuth 2.0도 권한 부여 코드 가로채기, 액세스 토큰(access token) 유출, CSRF(Cross-Site Request Forgery) 같은 공격을 전제로 보안 지침을 마련해 두고 있습니다(8). 예컨대 모든 통신은 TLS로 암호화해야 하고, 위조 요청을 막기 위해 state 매개변수를 쓰도록 강하게 권고합니다.

OAuth 2.0의 기본 개념은 무엇일까요?

oauth 2.0 개념

OAuth 2.0의 가장 기본 전제는 “내 비밀번호는 나만 알아야 한다”입니다. 예를 들어 어떤 사진 편집 앱이 Google Drive에 있는 제 사진을 가져와야 한다고 해서, 그 앱에 제 Google 비밀번호를 직접 알려주는 건 위험합니다.

OAuth 2.0은 이 문제를 ‘위임된 권한 부여(delegated authorization)’로 해결합니다. 제가 Google에게 “이 앱이 내 Drive 사진에 접근해도 된다”고 허락하면, Google이 앱에게 임시 허락증(토큰)을 발급해 주는 구조입니다. 덕분에 비밀번호는 보호되고, 앱은 필요한 기능만 수행할 수 있습니다.

OAuth 2.0을 이해하려면 네 가지 핵심 역할을 알아야 합니다. 비유로 정리하면 아래와 같습니다.

1. 자원 소유자(Resource Owner)는 정보의 진짜 주인, 즉 사용자입니다.
2. 자원 서버(Resource Server)는 정보를 실제로 보관하는 곳입니다. 예를 들면 Google Drive 서버입니다.
3. 클라이언트(Client)는 그 정보를 활용하고 싶은 앱이나 웹 서비스입니다. 사진 편집 앱 같은 것이 여기에 해당합니다.
4. 권한 부여 서버(Authorization Server)는 허락을 확인하고 토큰을 발급하는 곳입니다. Google 로그인/동의 화면을 떠올리면 됩니다.

이 네 가지가 맞물려야 정보가 안전하게 오갈 수 있습니다.

여기서 헷갈리는 포인트가 하나 있습니다. OAuth 2.0은 ‘인증(Authentication)’이 아니라, ‘권한 부여(Authorization)’에 특화된 기술입니다. 지문으로 은행 앱에 로그인하는 건 인증이고, 그 은행 앱이 다른 서비스에 내 카드 정보를 넘길 권한이 있느냐는 권한 부여입니다.

인증까지 같이 필요하면 OpenID Connect를 OAuth 2.0 위에 얹어서 쓰는 경우가 많습니다. 저는 이 차이를 명확히 잡아두는 게, OAuth를 실무에서 제대로 쓰는 첫 단추라고 봅니다.

OAuth 2.0에서 가장 중요한 개념은 토큰 기반 권한 부여입니다. 사용자의 비밀번호 대신 제한된 수명과 범위를 가진 액세스 토큰을 사용하면, 보안 침해가 발생해도 피해 범위를 좁힐 수 있습니다.

OAuth 2.0에서 핵심은 ‘토큰(Token)’입니다. 토큰은 ‘임시 허락증’이라고 생각하면 이해가 빠릅니다. 토큰은 크게 두 가지로 나뉩니다.

1. 액세스 토큰(Access Token)은 자원에 접근할 때 쓰는 핵심 허락증입니다. 보통 몇 분~몇 시간 내 만료됩니다.
2. 리프레시 토큰(Refresh Token)은 만료된 액세스 토큰을 새 토큰으로 교환할 때 쓰는 갱신용 허락증입니다. 유효 기간이 더 깁니다.

예를 들어 음악 스트리밍 앱에서 자동 로그인이 되는 이유도 리프레시 토큰 덕분인 경우가 많습니다. 다만 실무에서는 리프레시 토큰 관리가 정말 중요합니다. 이 토큰이 탈취되면 공격자가 새 액세스 토큰을 계속 발급받을 가능성이 커지기 때문입니다.

스코프(scope)는 클라이언트가 요청하는 권한 범위를 명확히 규정합니다(16, 17). 예를 들어 Google OAuth에서 “https://www.googleapis.com/auth/userinfo.email” 스코프는 이메일 주소 읽기 권한만 요청한다는 뜻입니다. 필요한 최소 권한만 요청하고, 사용자는 무엇을 허용하는지 정확히 알 수 있습니다. 이게 ‘최소 권한 원칙(principle of least privilege)’을 구현하는 핵심입니다.

OAuth 2.0 원리

oauth 2.0 flow

OAuth 2.0 flow는 클라이언트 앱이 보호된 자원에 접근하기 위해 액세스 토큰을 획득하는 전체 과정을 말합니다. OAuth 2.0은 크게 네 가지 grant type을 제공하고, 앱 유형(웹, 모바일, 서버 간 통신)과 보안 수준에 따라 선택해야 합니다.

처음에는 이 흐름이 복잡하게 느껴질 수 있습니다. 그런데 한 번 구조가 잡히면 “이 상황에서는 어떤 방식이 안전한가?”가 훨씬 명확해집니다.

가장 안전하고 널리 쓰이는 방식은 권한 부여 코드 흐름(Authorization Code Flow)입니다(1, 19). 주로 서버에서 구동되는 웹 서비스에 적합합니다. 진행 단계는 아래와 같습니다.

1. 앱이 사용자에게 권한 부여 서버(예: Google 로그인/동의 화면)로 이동하라고 안내합니다.
2. 사용자가 로그인하고 앱의 요청을 승인합니다.
3. 권한 부여 서버가 앱에게 권한 부여 코드(authorization code)를 발급하고, 등록된 redirect URI로 전달합니다.
4. 앱이 권한 부여 서버에 코드를 보내고, 클라이언트 시크릿(client secret) 등으로 자신을 증명한 뒤 액세스 토큰으로 교환합니다.
5. 앱이 발급받은 액세스 토큰으로 자원 서버에서 필요한 정보를 가져옵니다.

액세스 토큰이 브라우저에 직접 노출되지 않고 서버 간에 교환되기 때문에 보안성이 높습니다.

자원 소유자 비밀번호 자격 증명 흐름(Resource Owner Password Credentials Grant)은 사용이 금지됩니다. 암시적 흐름(Implicit Grant)은 금지까지는 아니지만, 사용하지 않을 것을 강하게 권고합니다. 토큰 유출 위험이 크고, 비밀번호 노출 구조는 더 이상 감당할 수 없는 수준이기 때문입니다.

2019년 IETF도 Implicit 대신 PKCE를 적용한 권한 부여 코드 흐름을 쓰라고 명확히 권고했습니다.

PKCE는 권한 부여 코드가 중간에 탈취되는 상황을 막기 위한 장치입니다. 특히 모바일 앱이나 브라우저 앱처럼 클라이언트 시크릿을 안전하게 보관하기 어려운 공개 클라이언트에서는 사실상 필수입니다.

모바일 앱이나 SPA 같은 공개 클라이언트에서 PKCE는 더 이상 선택이 아니라 필수 요구사항입니다. 기밀 클라이언트에서도 사용이 강하게 권장됩니다.

클라이언트 자격 증명 흐름(Client Credentials Flow)은 사용자 개입 없이 앱이 자신의 자격 증명(client ID, client secret)으로 액세스 토큰을 받는 방식입니다(1, 24). 서버 간 통신(M2M)에 주로 쓰입니다.

그리고 자원 소유자 비밀번호 자격 증명 흐름(Resource Owner Password Credentials Grant)은 최신 권장사항(RFC 9700)에서 사용을 강하게 금지합니다(20, 25). 사용자 비밀번호가 앱에 직접 노출되는 구조라서 위험이 너무 큽니다.

다음은 OAuth 2.0 권한 부여 방식(Grant Types) 비교 표입니다.

정리하면, 최신 보안 권장사항을 기준으로는 PKCE를 적용한 권한 부여 코드 흐름이 대부분의 시나리오에서 가장 안전하고 권장되는 방식입니다.

oauth 2.0 인증 방식

OAuth 2.0 인증 방식(authentication methods)은 클라이언트 앱이 “내가 등록된 그 앱이 맞다”는 것을 권한 부여 서버에 증명하는 절차입니다. 액세스 토큰을 요청하거나 리프레시 토큰으로 갱신할 때 이 과정이 들어갑니다.

실무에서 느끼는 건 단순합니다. 인증 방식을 잘못 잡으면, OAuth를 써도 전체 구조가 쉽게 흔들립니다.

OAuth 2.0은 클라이언트를 크게 두 유형으로 나눕니다.

1. 기밀 클라이언트(Confidential Clients)는 클라이언트 시크릿 같은 정보를 안전하게 보관할 수 있는 앱입니다. 서버 기반 웹 서비스가 대표적입니다.
2. 공개 클라이언트(Public Clients)는 시크릿을 안전하게 보관하기 어려운 앱입니다. 모바일 앱, 브라우저 기반 SPA가 여기에 해당합니다.

공개 클라이언트는 코드에 시크릿을 넣는 순간 노출된다고 봐야 합니다. 그래서 PKCE 같은 장치로 방어합니다.

기밀 클라이언트에서 흔히 쓰는 방식은 Client Secret Basic과 Client Secret Post입니다. 둘 다 네트워크로 시크릿이 전송되므로 TLS는 필수입니다.

더 강한 보안이 필요하면 Mutual TLS(mTLS) 기반 인증을 쓰기도 합니다. X.509 인증서를 활용해 양방향 인증을 구현하고, 중간자 공격 위험을 낮춥니다.

Private Key JWT(RFC 7523)는 비대칭 키로 JWT에 서명해 인증하는 방식입니다. 시크릿을 네트워크로 보내지 않기 때문에 유출 위험을 크게 줄일 수 있습니다. 환경에 따라 보안과 구현 복잡성 사이에서 균형을 잡아야 한다는 점도 같이 봐야 합니다.

IANA는 표준화된 인증 방법을 관리합니다. 여기에는 client_secret_basic, client_secret_post, private_key_jwt, tls_client_auth 등이 포함됩니다. 공개 클라이언트용 none도 명시되어 있고요.

다음은 주요 클라이언트 인증 방법 비교 표입니다.

OWASP는 OAuth 2.0 클라이언트 인증에서 아래 사항을 엄격히 권고합니다(39).

• 클라이언트 시크릿은 환경 변수나 보안 금고(vault)에 저장해야 한다
• 시크릿을 코드나 버전 관리 시스템에 직접 적지 않는다
• 시크릿은 주기적으로 갱신해야 한다
• 가능하면 비대칭 키 기반 인증(예: Private Key JWT)이 더 낫다

저도 신입 시절에 시크릿을 코드에 하드코딩한 채 배포할 뻔한 적이 있습니다. 그 뒤로는 보안 볼트 사용을 습관처럼 지키게 됐습니다.

OAuth 2.0 관련 표준

rfc 9700 oauth 2.0 security best current practice

RFC 9700, “Best Current Practice for OAuth 2.0 Security”는 2025년 1월 IETF BCP 240으로 발표된 문서입니다. OAuth 2.0 구현 시 반드시 지켜야 할 최신 보안 규칙을 정리해 둔 기준점이라고 보시면 됩니다.

저는 이 문서가 나오자마자 기존 시스템 설계를 다시 점검했습니다. 표준이 바뀌면, 공격자도 그 표준을 기준으로 빈틈을 찾기 때문입니다.

RFC 9700에서 가장 중요한 변화 중 하나는 PKCE의 적용 범위가 넓어졌다는 점입니다. 공개 클라이언트는 PKCE 사용이 의무이고, 기밀 클라이언트에도 사용이 강하게 권장됩니다. 권한 부여 서버는 PKCE를 반드시 지원해야 합니다.

그리고 암시적 흐름(Implicit Grant)과 자원 소유자 비밀번호 자격 증명 흐름(Resource Owner Password Credentials Grant)은 명시적으로 금지합니다. 이유는 단순합니다. 토큰 유출 위험이 크고, 비밀번호 노출 구조는 더 이상 감당할 수 없는 수준이기 때문입니다.

RFC 9700은 발신자 제한 액세스 토큰(sender-constrained access tokens)도 강력히 권장합니다. 토큰을 특정 클라이언트나 TLS 세션에 묶어버리면, 토큰이 탈취돼도 다른 곳에서 악용하기가 훨씬 어려워집니다. RFC 8705(mTLS)나 RFC 9449(DPoP)로 구현할 수 있습니다.

리디렉션 URI도 엄격하게 매칭해야 합니다. 와일드카드나 부분 일치는 허용하면 안 됩니다. 오픈 리디렉션(open redirect) 공격을 막기 위한 필수 조건입니다.

리프레시 토큰 보안도 강화합니다. 대표적으로 리프레시 토큰 로테이션(refresh token rotation), 발신자 제한, 짧은 유효 기간, 재사용 탐지 시 전체 토큰 무효화 같은 요구사항이 포함됩니다. 컨설팅을 할 때도 이 부분을 가장 먼저 체크하는 편입니다.

다음은 RFC 9700 주요 요구사항 요약 표입니다.

 

RFC 9700은 클라이언트가 CSRF를 반드시 막도록 요구합니다. PKCE나 OpenID Connect의 nonce가 CSRF 방어를 제공하며, 둘 다 쓸 수 없는 경우에는 state 매개변수에 일회용 CSRF 토큰을 담아 사용해야 합니다.

또한 권한 부여 코드는 최초 사용 후 반드시 무효화되어야 하며, 수명은 가능한 짧게 유지하는 것이 원칙입니다.

rfc 7009 oauth 2.0 token revocation

RFC 7009, “OAuth 2.0 Token Revocation”은 2013년 8월 발행된 표준입니다. 더 이상 필요 없거나 보안상 문제가 생긴 액세스 토큰과 리프레시 토큰을 명확히 ‘취소(revoke)’하는 기능을 정의합니다.

토큰 취소 기능이 없으면, 한 번 발급된 토큰은 만료될 때까지 계속 유효합니다. 이게 실무에서는 꽤 큰 리스크가 됩니다.

취소 엔드포인트(revocation endpoint)는 보통 “/revoke” 같은 경로로 제공됩니다. 요청에는 token 매개변수와, 선택적으로 token_type_hint(예: access_token, refresh_token)를 보냅니다.

RFC 7009는 토큰 취소 요청에도 클라이언트 인증을 요구합니다. 기밀 클라이언트는 시크릿 등으로 인증해야 하고, 공개 클라이언트는 최소한 클라이언트 ID를 제공해야 합니다. 다른 앱의 토큰을 함부로 취소하지 못하게 막는 장치입니다.

중요한 규칙도 있습니다. 리프레시 토큰이 취소되면, 그 토큰에서 파생된 모든 액세스 토큰도 함께 무효화되어야 합니다. 리프레시 토큰이 사실상 ‘마스터 키’ 역할을 하기 때문입니다.

응답은 보통 HTTP 200 OK이고 본문은 비어 있습니다. 이미 무효화된 토큰을 취소 요청해도 성공으로 처리하는데, 토큰 존재 여부를 추측하는 공격을 막기 위한 설계입니다.

토큰 무효화 시나리오별 동작 요약 표입니다(51, 59).

RFC 7009는 요청 제한(rate limiting) 구현도 권고합니다. 무차별 대입이나 서비스 거부 공격을 막기 위한 장치입니다. 그리고 토큰 취소는 비동기적으로 처리될 수도 있다는 점도 인정합니다. 즉, 취소 요청이 들어가도 자원 서버 전체에 전파되기까지 시간이 걸릴 수 있습니다.

토큰 취소는 RFC 7662의 토큰 인트로스펙션(Token Introspection)과 같이 쓰면 효과가 커집니다. 자원 서버가 토큰 상태를 실시간으로 확인하고, 취소된 토큰을 즉시 거부할 수 있기 때문입니다.

—

여기까지 OAuth 2.0의 핵심 개념, 작동 원리, 그리고 최신 보안 표준(RFC 9700, RFC 7009)을 중심으로 흐름을 정리해 봤습니다. OAuth 2.0은 단순한 “로그인 편의 기능”이 아니라, 사용자 비밀번호를 보호하면서 서비스 연동을 가능하게 만드는 권한 위임 구조입니다.

실무에서는 결국 한 가지로 귀결됩니다. 편리함을 유지하면서도, 토큰과 리디렉션, PKCE 같은 기본 보안 장치를 얼마나 꼼꼼히 챙기느냐입니다. 이 부분을 놓치면, OAuth를 썼다는 사실 자체가 큰 의미가 없어집니다.

FAQ

Q1: OAuth 2.0은 인증(Authentication)과 권한 부여(Authorization) 중 어떤 것에 중점을 둡니까?
A1: OAuth 2.0은 권한 부여(Authorization)에 중점을 둡니다. 사용자가 비밀번호를 제3자 앱에 직접 제공하지 않고도, 특정 앱이 다른 서비스의 자원에 제한적으로 접근하도록 권한을 위임하는 메커니즘입니다. 인증(Authentication)은 OpenID Connect 같은 추가 프로토콜로 OAuth 2.0 위에 구현하는 방식이 일반적입니다.

Q2: OAuth 2.0에서 PKCE는 왜 중요하며, 어떤 클라이언트 유형에 필수적입니까?
A2: PKCE는 authorization code 가로채기 공격을 막기 위해 중요합니다. 특히 client secret을 안전하게 보관하기 어려운 모바일 앱이나 SPA 같은 공개 클라이언트(Public Clients)에 필수입니다. 그리고 RFC 9700 기준으로 공개 클라이언트는 PKCE가 의무이며, 기밀 클라이언트에도 사용이 강하게 권장됩니다.

Q3: RFC 9700에서 Implicit Grant와 Resource Owner Password Credentials Grant를 권장하지 않는 이유는 무엇입니까?
A3: Implicit Grant는 access token이 URL에 노출되어 token leakage 위험이 커지고, Resource Owner Password Credentials Grant는 사용자 비밀번호를 클라이언트에 직접 노출시키는 구조라 보안 취약점이 큽니다. 그래서 RFC 9700은 비밀번호 자격 증명 방식을 금지하고 암시적 방식은 강하게 비권장하며, PKCE를 적용한 Authorization Code Grant를 권장합니다.

Q4: OAuth 2.0에서 refresh token이 무효화되면 access token에는 어떤 영향을 미칩니까?
A4: RFC 7009에 따르면 refresh token이 무효화되면, 해당 refresh token에서 파생된 모든 access token도 함께 무효화되어야 합니다. refresh token이 새 access token을 발급하는 ‘마스터 키’ 역할을 하기 때문입니다.

Q5: OAuth 2.0 클라이언트 인증 시 Client Secret Basic 외에 더 강력한 보안을 제공하는 방법은 무엇이 있습니까?
A5: 더 강한 보안을 원하면 Private Key JWT(RFC 7523)나 Mutual TLS(RFC 8705)를 고려할 수 있습니다. Private Key JWT는 비대칭 키로 JWT를 서명해 client secret 전송 없이 인증하고, Mutual TLS는 X.509 인증서를 통한 양방향 인증으로 보안 수준을 크게 끌어올립니다. 특히 금융 서비스 같은 고위험 환경에서 권장됩니다.