OAuth 2.0 이해와 TikTok Shop API 연동하기

사내에서 통합 쇼핑몰 연동서비스에 새롭게 동남아 시장을 겨냥하여, TikTok Shop 오픈마켓 연동을 담당하게 됐습니다. TikTok Shop  API 를 연동하면서 TikTok Shop 에선 인증인가를 OAuth 2.0 방식을 사용하길래, 공부도할 겸 글로 작성해보았습니다.

 

현대 웹 서비스에서 OAuth 2.0 가 매우 널리 사용됩니다. 특히, 많은 개발자들이 단순히 '소셜 로그인' 기술로만 알고 있는 OAuth 2.0의 본질적인 목적과, 현업에서 가장 많이 사용되는 Authorization Code Flow의 동작 원리, 그리고 OpenID Connect(OIDC)를 통한 인증(Authentication) 확장까지 명확히 정리해 드리고자 합니다.

 

 

 

🔐OAuth 2.0 — 인가(Authorization)를 위한 표준 프로토콜

 

대부분의 팀이 서비스를 개발할 때, 구글 캘린더나 트위터 API와 같은 타사 서비스의 API를 이용하고자 하는 아이디어를 갖게 됩니다. 이 타사 리소스에 접근하기 위해 과거에는 어떤 방식을 사용했을까요?

 

OAuth가 없던 시절에는, 서비스가 사용자(Resource Owner)의 구글 캘린더에 접근하기 위해 사용자로부터 구글 아이디와 패스워드를 직접 전달받아 로그인을 수행해야 했습니다.

 

이 방식은 치명적인 보안 문제를 야기합니다.

• 사용자 신뢰 문제
  사용자는 ID와 비밀번호를 제공함으로써, 캘린더 정보뿐만 아니라 구글 포토, 구글 드라이브 등 원하지 않는 모든 서비스에 접근할 권한을 넘겨주게 됩니다.
  
  
• 클라이언트 관리 부담
  개발한 서비스(클라이언트)는 수많은 사용자의 민감한 구글 인증 정보를 관리해야 하는 보안적 부담을 안게 됩니다. 만약 이 정보가 노출된다면 서비스는 심각한 법적 문제를 갖게 될 것입니다.
  
  
• 리소스 제공자 보안 무력화
  구글이 아무리 보안 수준을 높여도, 외부에서 사용자 ID/PW가 노출된다면 모든 보안 조치가 무용지물이 됩니다.

결국, 이 모든 문제는 클라이언트가 ID와 패스워드를 직접 관리하는 데서 발생합니다

 

 

 

 

🔰OAuth의 핵심 원칙: "인증"과 "인가"의 분리

 

클라이언트(개발한 애플리케이션)가 필요한 것은 리소스(타사 서비스의 리소스: 구글 캘린더)에 접근할 수 있는 권한(Authorization), 즉 인가입니다.

이 인가를 위해서는 인증(Authentication)이 선행되어야 합니다.

OAuth는 이 문제를 해결하기 위해 인증과 인가의 대상을 분리합니다.

인증 (Authentication): 사용자가 리소스 제공자에게 직접 수행합니다.

인가 (Authorization): 인증 후, 리소스 접근 권한을 클라이언트가 위임받습니다.

 

사용자는 타사 서비스에 비밀번호를 주지 않고(인증은 유저가 직접), 서비스 제공자가 발급해주는 "토큰"(권한은 서비스에게 위임)만 맡깁니다.

 

 

💠OAuth 2.0의 주요 구성 요소

구글 캘린더로 예시를 들어보겠습니다.

주체 (Role)	예시	역할
Resource Owner (리소스 오너)	사용자 (User)	인증을 수행하는 주체.
Client (클라이언트)	사내에서 개발한 서비스	권한을 위임받는 주체.
Authorization Server (인가 서버)	구글의 인증 서버	인증 검증 및 권한 부여를 담당.
Resource Server (리소스 서버)	구글 캘린더 API	인가를 수행하고 리소스를 제공.

 

 

1. Resource Owner (리소스 오너)

리소스 오너는 자신이 소유한 보호된 리소스(Protected Resource)에 접근할 수 있는 권한을 부여할 수 있는 주체를 의미합니다.

• 역할: 일반적으로는 서비스를 이용하는 최종 사용자(End-User)입니다. (예: 구글 캘린더 일정을 가진 사용자, 틱톡 샵의 판매자 계정 주인)
• 권한 부여: 클라이언트가 자신의 리소스에 접근하도록 허용할지 말지를 결정하며, 인가 서버에 직접 인증(Authentication)을 수행하여 이를 입증합니다.

---

2. Client (클라이언트)

클라이언트는 리소스 오너를 대신하여 보호된 리소스에 접근하기 위해 권한을 요청하고, 그 권한을 위임받아 리소스 서버에 요청을 보내는 애플리케이션입니다.

• 역할: 실제로 기능을 제공하는 서비스 (예: 틱톡 샵 서비스를 연동하려는 앱)
• 식별 및 보안: OAuth 제공자에게 사전에 등록하여 Client ID와 Client Secret을 발급받습니다. Client ID는 클라이언트를 식별하며, Client Secret은 토큰 교환 단계에서 클라이언트의 신원을 증명하는 데 사용됩니다.
• Redirection URI: 인가 코드를 전달받을 콜백(Callback) 주소를 인가 서버에 미리 등록해야 합니다.

---

3. Authorization Server (인가 서버)

인가 서버는 클라이언트에게 Access Token을 발급하는 역할을 전담하는 주체입니다. 이 서버는 리소스 오너의 인증 정보를 확인하고, 클라이언트에게 리소스 접근 권한을 부여하는 핵심 게이트웨이입니다.

• 역할: 리소스 오너의 인증을 검증하고(사용자 로그인 확인), 유효할 경우 클라이언트에게 인가 코드(Authorization Code)와 최종적으로 Access Token을 발급합니다. (예: Google OAuth Server, TikTok Shop Open Authorization Center)
• 보안: Access Token 발급 시, 클라이언트의 Client Secret을 검증하여 보안을 강화합니다.

---

4. Resource Server (리소스 서버)

리소스 서버는 보호된 리소스를 호스팅하고, 클라이언트로부터 받은 Access Token을 검증하여 클라이언트가 요청한 리소스(데이터)를 제공하는 주체입니다.

• 역할: 실제 API 엔드포인트를 제공합니다. (예: Google Calendar API, TikTok Shop Open API)
• 인가 수행: 클라이언트가 전송한 Access Token의 유효성과, 토큰이 부여된 권한 범위(Scope)가 요청된 리소스에 접근하기에 충분한지 확인한 후 리소스를 응답합니다. Access Token이 없거나 유효하지 않으면 요청을 거부합니다.

 

 

 

🔢OAuth 2.0의 대표 흐름 — Authorization Code Flow

 

OAuth 2.0에는 여러 Grant Type이 있지만, 실제 프로덕션 환경에서 가장 널리 쓰이는 방식은 Authorization Code Flow입니다. 틱톡 샵의 Open API Document 에서 제공해주는 틱톡샵 OAuth 시퀀스 다이어그램을 기반으로 이 흐름을 단계별로 분석해 보겠습니다.

 

 

0단계: 클라이언트 등록 및 설정

OAuth를 사용하기 위해서는 먼저 제공자의 API에 저희의 서비스를 등록해야 합니다.

• Client ID: 서비스의 식별자.
• Client Secret: 클라이언트가 실제로 인증된 주체인지 확인하기 위한 비밀번호.
• Redirection URI: 권한을 다시 서비스에게 반환받을 엔드포인트. OAuth 사용을 위한 기본 조건이며, 브라우저의 리다이렉션이 필요합니다.
• Scope (권한 범위): 클라이언트가 요청하는 API 권한의 종류를 제한합니다. (e.g. 상품 API, 주문 API, 물류 API 등)

 

1단계: 인가 코드 요청 및 인증 수행 (User Interaction)

이 단계는 리소스 오너(User)가 클라이언트(Service/App)에게 권한을 위임하기 위해 인가 서버(Authorization Server)와 상호작용하는 과정입니다.

단계	TikTok Shop OAuth 흐름	OAuth 2.0 역할 설명
①~② 초기 진입	User가 TikTok Shop 파트너 센터에서 Service/App에 대한 구독/사용 승인을 한 후, Service/App의 웹사이트(로그인 페이지) 링크로 이동합니다.	클라이언트가 권한 위임을 시작하는 시점입니다.
③ 인가 요청 (Authorization Request)	Service/App은 TikTok Shop Open Authorization Center의 인증 서버 URL로 User의 브라우저를 리다이렉션합니다. 이때 service_id 또는 app_key (클라이언트 식별자)와 CSRF 방지를 위한 state 파라미터를 함께 전달합니다.	client_id (app_key), redirect_uri, scope 등의 파라미터가 포함된 인가 요청입니다.
④ 인증 (Authentication)	User는 TikTok Shop Open Authorization Center에서 계정 정보(예: 판매자 로그인)와 비밀번호를 입력하여 직접 인증을 수행합니다.	클라이언트는 이 인증 과정에 전혀 관여하지 않으며, 계정 정보가 유출될 위험이 원천적으로 차단됩니다.

 

 

2단계: 인가 코드 발급 및 교환 (Token Exchange)

User 인증이 완료된 후, 클라이언트(Service/App)는 인가 코드(Auth Code)를 이용해 Access Token을 교환합니다. 이 과정은 클라이언트 서버와 인가 서버 간의 직접 통신으로 이루어지는 것이 핵심입니다.

단계	TikTok Shop OAuth 흐름	OAuth 2.0 역할 설명
⑤ 인가 코드 발급 (Authorization Code Grant)	Authorization Center는 인증이 유효하다고 판단되면, auth code를 생성하고 사전에 등록된 redirect URL (Callback URI)과 함께 User의 브라우저를 Service/App으로 리다이렉션합니다.	클라이언트가 권한을 임시로 받을 수 있는 일회성 코드를 획득합니다.
⑥ Access Token 요청 (Token Request)	Service/App 서버는 수신한 auth code를 사용하여 Authorization Center에 Access Token 발급을 직접 요청합니다. 이때 요청 파라미터로 app_key, app_secret, auth_code, grant_type (authorization_code), granted_scopes 등을 포함합니다.	서버 간의 안전한 통신을 통해 app_secret을 검증하여, 요청 주체가 등록된 정식 클라이언트임을 확인합니다.
⑦ Access Token 발급	Authorization Center는 유효성을 확인한 후, access_token (실제 권한), refresh_token (토큰 갱신용), 그리고 open_id (사용자 식별자, OIDC 요소)를 응답 파라미터로 Service/App 서버에 직접 반환합니다.	이 서버 대 서버 통신은 보안 강화를 위해 반드시 HTTPS로 암호화되어야 합니다.

 

 

3단계: 리소스 접근 및 서비스 제공

클라이언트가 획득한 Access Token을 활용하여 최종적으로 리소스 서버에 접근하는 단계입니다.

 

단계	TikTok Shop OAuth 흐름	OAuth 2.0 역할 설명
⑧ Open API 요청 (Resource Access)	Service/App은 발급받은 access_token을 헤더 등에 포함하여 TikTok Shop Open API (리소스 서버)에 원하는 정보를 요청합니다.	Access Token은 클라이언트가 위임받은 권한 범위(Scope) 내에서만 리소스 접근이 가능하도록 제한합니다.
⑨~⑩ 결과 표시	Open API가 요청 결과를 반환하면, Service/App은 이를 가공하여 User에게 표시합니다.	서비스를 완성하고 사용자에게 가치를 제공하는 최종 단계입니다.

 

 

 

💡번외 - 소셜 로그인과 OpenID Connect (OIDC)

많은 개발자들이 OAuth 2.0을 소셜 로그인에 사용하지만, 앞서 강조했듯이 OAuth의 본질은 인가(Authorization) 기술입니다.

 

OAuth 2.0을 활용한 소셜 로그인

OAuth는 인가를 위한 기술이지만, 이를 통해 사용자의 식별 정보를 얻어 인증(로그인)을 구현할 수 있습니다.

1. Access Token 획득: 위 3단계까지 동일하게 Access Token을 발급받습니다.
2. 사용자 프로필 요청: 획득한 Access Token을 이용해 리소스 서버에 사용자의 프로필(식별자) 정보를 요청합니다.
3. 서비스 내부 인증: 클라이언트는 이 프로필 정보를 기반으로 서비스의 별도 멤버 DB에서 사용자를 조회하거나 신규 생성합니다.
4. 세션 생성: 서비스 내부적으로 사용할 JWT 등의 토큰을 생성하여 사용자에게 반환, 로그인 세션을 유지합니다.

주의: OAuth가 ID/PW 관리를 위임해 주지만, 사용자의 찜 정보, 일정 등 서비스 특화 정보를 관리하기 위해 별도의 멤버 DB 구축은 필수입니다.

 

 

OpenID Connect (OIDC)의 등장

인증(Authentication)을 명확히 지원하기 위해 OAuth 2.0 위에 구축된 기술이 바로 OpenID Connect입니다.

• ID Token: OIDC는 Access Token 요청 시, 추가적으로 사용자 인증 정보를 담고 있는 ID Token의 발급을 요청합니다.
• JWT 기반: ID Token은 JWT(JSON Web Token) 형태로 이루어져 있어, 페이로드를 디코딩하여 사용자의 식별자를 얻을 수 있습니다.

따라서, OIDC를 지원하는 서비스라면 Access Token 대신 ID Token을 통해 사용자 인증 정보를 얻어와 소셜 로그인을 구현하는 것이 가장 표준적인 방법입니다.

 

틱톡 샵의 Access Token 발급 단계(⑦) 응답 파라미터를 보면 open_id가 포함되어 있습니다. 이 open_id는 사용자를 식별할 수 있는 고유값으로, 이는 OpenID Connect(OIDC) 기술이 OAuth 2.0 기반 위에서 사용자 인증(Authentication) 정보를 제공하도록 확장되었음을 보여줍니다.

• OAuth 2.0의 본질: 인가(Authorization)
• OpenID Connect (OIDC): OAuth 2.0 위에 구축되어 인증(Authentication) 레이어를 추가한 프로토콜. ID Token이나 open_id 같은 사용자 식별자를 제공합니다.

 

✨마무리 하며

OAuth 2.0은 인가 과정에서 인증을 사용자에게 분리하여, 클라이언트가 직접 민감한 인증 정보를 다루지 않고도 필요한 권한을 안전하게 위임받을 수 있도록 설계된 핵심 보안 기술입니다.

현대의 백엔드 개발자로서 이 인가(Authorization) 흐름을 명확히 이해하고, 소셜 로그인 구현 시 OAuth와 OIDC의 차이점을 인지하여 표준적인 방식으로 구현하는 것이 중요합니다.