OAuth 2.0?
OAuth 2.0은 웹 및 애플리케이션에서 인증과 권한 부여를 위한 개방형 표준 프로토콜입니다.
이 프로토콜은 타사 애플리케이션이 사용자의 리소스에 접근할 수 있는 절차를 정의하고, 서비스 제공자의 API를 사용할 수 있는 권한을 부여합니다. 대표적인 사례로 네이버 로그인 같은 소셜 로그인이 있습니다.
OAuth 2.0의 구성 요소
OAuth 2.0은 총 네 가지 주요 구성 요소로 이루어집니다
- 리소스 소유자(Resource Owner): 웹 서비스를 이용하는 사용자
- 클라이언트(Client): 자사 또는 개인이 만든 애플리케이션 서버
- 권한 서버(Authorization Server): 인증과 권한 부여를 담당하는 서버.
- 리소스 서버(Resource Server): 사용자 정보를 보유한 서버(ex. 구글, 카카오)
하지만 OAuth를 사용한다해서 전부 동일한 동작 방식을 가지고 있지는 않습니다. 동작 방식의 차이점을 네이버 스마트 스토어 인증 방법과 네이버 소셜 로그인을 통해 알아봅시다.
네이버 스마트 스토어 인증 방법
네이버 커머스 API를 사용하려면, 네이버로부터 쇼핑몰 통합 매니저의 권한(AUTHORIZATIONS)을 부여받아야 합니다.
커머스 API 인증 방식
네이버 커머스 API는 OAuth 2.0 규약에 따라 인증을 수행하며, 특히 서버 간 연동을 위해 Client Credentials Grant방식을 사용합니다
Client Credentials Grant 방식
이 방식은 클라이언트가 외부에서 액세스 토큰을 획득하여 특정 리소스에 접근할 때 사용됩니다. 인증 절차는 간단하며 다음과 같습니다
- 클라이언트가 Client ID와 Client Secret을 POST 방식으로 인증 서버에 전송
- 인증 서버(ex. 네이버)가 ID와 Secret의 유효성을 검사
- 유효하다면 인증 서버는 클라이언트에게 액세스 토큰을 발급
- 클라이언트는 API 요청 시 헤더에 발급받은 토큰(Bearer ACCESS_TOKEN)을 첨부하여 리소스를 요청
- API 엔드포인트는 클라이언트에게 리소스를 전달.
소셜 로그인 인증 방식
구글이나 네이버의 소셜 로그인은 Authorization Code Grant 방식을 사용하며, 이는 커머스 API의 Client Credentials Grant 방식과 다르게 동작합니다
Authorization Code Grant 방식
이 방식은 클라이언트가 사용자를 대신하여 특정 자원에 접근할 때 사용됩니다.
특징적인 점은 ID/PW의 유효성 검증 후 바로 액세스 토큰을 발급하지 않고, Authorization Code를 먼저 발급받아 이를 사용해 다시 액세스 토큰을 요청한다는 점입니다.
이 과정에서 인증 서버가 Authorization Code를 발급하며, 액세스 토큰은 리소스 서버에서 발급됩니다.
리디렉션이 두 번 발생하는 이유
사용자가 애플리케이션에서 소셜 로그인 버튼을 클릭하면, 소셜 플랫폼의 인증 서버로 리디렉션됩니다.
사용자가 소셜 플랫폼에서 로그인 및 권한 승인을 완료하면, Authorization Code가 redirect_uri에 지정된 애플리케이션의 엔드포인트로 리디렉션됩니다.
애플리케이션은 이 Authorization Code를 이용해 소셜 플랫폼의 인증 서버에 액세스 토큰을 요청하고, 최종적으로 토큰을 받아 필요한 리소스에 접근할 수 있습니다.
즉,
첫 번째 리디렉션: 사용자를 소셜 로그인 페이지로 이동
두 번째 리디렉션: 사용자가 승인을 마친 후 애플리케이션으로 돌아옴
이러한 과정은 OAuth 2.0 프로토콜의 보안과 인증 절차의 일환입니다.
