OAuth 2.0의 개념

OAuth 2.0(Open Authorization 2.0)은 인터넷 서비스(애플리케이션)가 사용자의 비밀번호를 직접 제공받지 않고도, 사용자를 대신해 다른 서비스의 특정 데이터에 접근할 수 있도록 권한을 위임(Authorization)하는 개방형 표준 프로토콜입니다.

• 원리 및 구체적 예시: 사용자가 'A'라는 일정 관리 앱(Client)을 사용할 때, 이 앱이 사용자의 구글 캘린더 정보에 접근해야 한다고 가정해 보겠습니다. 과거에는 'A' 앱에 구글 아이디와 비밀번호를 직접 입력해야 했지만, 이는 보안상 매우 위험합니다. OAuth 2.0을 사용하면 구글(Authorization Server)이 사용자 본인 확인을 거친 후 'A' 앱에게 캘린더 정보만 읽을 수 있는 '접근 토큰(Access Token)'을 발급합니다.
• 이는 호텔의 마스터키(비밀번호)를 통째로 넘기는 대신, 정해진 방에만 출입할 수 있는 임시 키카드(Access Token)를 발급해 주는 것과 같은 원리입니다.

---

OAuth 2.0의 주요 구성 요소

복잡한 상호작용을 명확히 이해하기 위해 OAuth 2.0을 구성하는 4가지 핵심 주체를 표로 구조화했습니다.

구성 요소 (Role)	설명	예시
Resource Owner	자신의 정보(자원)에 대한 접근 권한을 부여하는 주체입니다.	서비스를 이용하는 일반 사용자
Client	Resource Owner를 대신하여 보호된 자원에 접근하려는 서드파티 애플리케이션입니다.	사용자가 이용하려는 일정 관리 앱
Authorization Server	Resource Owner의 동의를 얻어 Client에게 Access Token을 발급하는 서버입니다.	Google, Kakao의 인증 서버
Resource Server	사용자의 실제 데이터(자원)를 보관하고 있으며, Access Token을 확인하고 데이터를 제공하는 서버입니다.	Google Calendar API 서버

---

OAuth 2.0 동작 원리 (가장 일반적인 Authorization Code 방식)

가장 보안성이 높고 널리 쓰이는 Authorization Code Grant(권한 부여 코드 승인) 방식의 동작 절차는 다음과 같습니다.

1. 권한 요청: Client가 사용자(Resource Owner)를 Authorization Server의 로그인 화면으로 리다이렉트 시킵니다.
2. 인증 및 권한 부여: 사용자가 자신의 계정으로 로그인한 후, Client가 요청하는 권한(예: 캘린더 읽기)을 승인합니다.
3. Authorization Code 발급: Authorization Server는 Client가 사전에 등록해 둔 Redirect URI로 임시 비밀번호 격인 'Authorization Code'를 전달합니다.
4. Access Token 요청: Client는 전달받은 Authorization Code와 자신의 자격 증명(Client ID/Secret)을 Authorization Server로 직접(백엔드 통신) 전송하여 Access Token을 요청합니다.
5. Access Token 발급: Authorization Server는 전달받은 정보가 유효한지 검증한 후, 최종적으로 Access Token을 발급합니다.
6. 자원 접근: Client는 이 Access Token을 HTTP 헤더에 담아 Resource Server에 데이터를 요청하고, 성공 시 데이터를 응답받습니다.

---

주의: 인가(Authorization) vs 인증(Authentication)

실무에서 가장 많이 혼동하는 개념이며, 명확히 구분해야 합니다.

• 인가 (Authorization): OAuth 2.0의 본래 목적입니다. "이 애플리케이션이 특정 데이터에 접근할 권한이 있는가?"를 검증합니다.
• 인증 (Authentication): "이 사용자가 누구인가?"를 확인합니다. 순수 OAuth 2.0은 인증 프로토콜이 아니기 때문에, '소셜 로그인(SSO)'과 같이 사용자의 신원을 확인하는 인증 용도로 사용하기 위해 OAuth 2.0 위에서 동작하는 OIDC(OpenID Connect)라는 확장 프로토콜을 함께 사용하는 것이 현대의 표준입니다.

---

OAuth 2.0의 4가지 주요 권한 부여 방식(Grant Types)

OAuth 2.0은 클라이언트 애플리케이션의 구동 환경(웹 서버, 브라우저, 모바일, 서버 간 통신 등)과 신뢰 수준에 따라 4가지 주요 권한 부여 방식을 제공합니다. 각 방식의 핵심 차이를 먼저 표로 요약한 후, 구체적인 원리와 예시를 설명해 드리겠습니다.

권한 부여 방식 (Grant Type)	주요 사용 환경	보안성	Access Token 전달 방식	최신 보안 권고 (OAuth 2.1)
Authorization Code	백엔드 서버가 있는 웹 애플리케이션	매우 높음	코드를 교환하여 Back-end로 전달	적극 권장 (표준)
Implicit	브라우저 기반 앱 (과거 SPA)	낮음 (유출 위험)	URL을 통해 브라우저로 직접 노출	사용 금지 (Deprecated)
Resource Owne Password	1사 (1st-party) 공식 애플리케이션	낮음 (Client가 PW 취급)	Client가 직접 ID/PW를 받아 전달	사용 금지 (Deprecated)
Client Credentials	사용자 개입 없는 서버 대 서버 (B2B)	높음	Client 자격증명만으로 발급	적극 권장 (B2B용)

---

1. 권한 부여 코드 승인 방식 (Authorization Code Grant)

가장 안전하고 보편적으로 사용되는 표준 방식입니다. Access Token을 사용자(브라우저)에게 직접 노출하지 않고, 클라이언트의 백엔드 서버와 인증 서버 간의 통신을 통해 안전하게 교환합니다.

• 원리: 인증 서버는 사용자 로그인 성공 시 Access Token 대신 임시 비밀번호 격인 'Authorization Code'를 브라우저로 먼저 전달합니다. 클라이언트의 백엔드 서버는 이 코드를 가로채어 자신의 Client Secret과 함께 인증 서버로 보내 Access Token으로 교환합니다.
• 구체적 예시: 일반적인 웹 사이트에서 '구글로 로그인' 버튼을 클릭하여 가입하는 경우. 브라우저 주소창에 ?code=xxxxxxxx 형태의 임시 코드가 잠깐 나타났다가 사라지고 로그인이 완료되는 방식입니다.

2. 암묵적 승인 방식 (Implicit Grant)

과거 백엔드 서버가 없는 Single Page Application(SPA) 환경을 위해 만들어진 간소화된 방식입니다.

• 원리: 복잡한 Authorization Code 교환 단계를 생략하고, 인증 서버가 사용자 로그인 즉시 Access Token을 브라우저의 URL 프래그먼트(해시 # 뒤, 예: #access_token=xxxx)에 담아 직접 반환합니다.
• 구체적 예시: 백엔드 없이 순수 React, Vue.js 등으로만 구성된 정적 웹 페이지에서 토큰을 받아 즉시 API를 호출할 때 사용되었습니다.
• 최신 보안 동향: Access Token이 URL에 명시적으로 노출되어 탈취 위험이 매우 높습니다. 최신 보안 권고안인 OAuth 2.1에서는 이 방식의 사용을 전면 금지하고 있으며, 대신 'Authorization Code 방식 + PKCE(Proof Key for Code Exchange)'를 결합하여 사용할 것을 강력히 권장합니다.

3. 자원 소유자 자격증명 승인 방식 (Resource Owner Password Credentials Grant)

사용자(Resource Owner)의 아이디와 비밀번호를 클라이언트 애플리케이션이 직접 입력받아 Access Token을 요청하는 방식입니다.

• 원리: OAuth 2.0의 본래 목적인 '비밀번호 위임'에 정면으로 위배되는 방식입니다. 클라이언트가 사용자의 ID와 PW를 그대로 인증 서버로 전달하여 토큰을 받아옵니다.
• 구체적 예시: 서드파티 앱이 아닌, 동일한 회사가 만든 공식 모바일 앱과 자사 백엔드 API 간의 통신 등 클라이언트와 인증 서버가 완벽히 신뢰할 수 있는 관계일 때만 제한적으로 사용되었습니다.
• 최신 보안 동향: 클라이언트가 사용자의 비밀번호를 취급해야 한다는 치명적인 단점 때문에, 이 방식 역시 최신 표준(OAuth 2.1)에서는 폐기(Deprecated)되었습니다.

4. 클라이언트 자격증명 승인 방식 (Client Credentials Grant)

사용자(Resource Owner)의 개입이나 동의가 전혀 필요 없는 방식입니다. 애플리케이션(Client) 자체가 자신의 자원이나 권한을 요청할 때 사용합니다.

• 원리: 클라이언트 애플리케이션이 사전에 발급받은 자신의 자격증명(Client ID, Client Secret)만을 인증 서버로 보내 Access Token을 발급받습니다.
• 구체적 예시: 백그라운드에서 주기적으로 실행되는 데이터 동기화 배치(Batch) 프로그램이나, 결제 처리 서버가 카드사 API 서버와 통신하는 등 서버 대 서버(Server-to-Server, B2B) 백그라운드 통신에 주로 사용됩니다.