안녕하세요. IT 엘도라도 에 오신 것을 환영합니다.
글을 쓰는 것은 귀찮지만 다시 찾아보는 것은 더 귀찮습니다.
완전한 나만의 것으로 만들기 위해 지식을 차곡차곡 저장해 보아요.   포스팅 둘러보기 ▼

웹, 앱 (Web, Application)

[Web] OAuth 2.0 (카카오, 페이스북, 구글 등의 소셜 서비스 연동)

피그브라더 2021. 1. 7. 22:21

특정 서비스를 이용하다 보면 카카오 로그인, 페이스북 로그인, 구글 로그인 등의 기능을 본 적이 있을 것이다. 이는 해당 서비스를 위해 별도의 번거로운 회원가입 절차를 진행하지 않고도 이미 가지고 있는 카카오 계정, 페이스북 계정, 구글 계정으로 간편하게 서비스를 이용할 수 있도록 해주는 기능이다. 이 기술의 핵심이 바로 OAuth 2.0이다. 즉 OAuth 2.0은 특정 서비스에서 카카오, 페이스북, 구글 등의 소셜 서비스를 연동할 수 있도록 돕는 기술이다. 이번 포스팅에서는 OAuth 2.0의 핵심적인 개념만을 설명할 것이다. 각 웹 어플리케이션 혹은 라이브러리가 구체적으로 이러한 OAuth 2.0을 어떻게 이용하여 소셜 로그인을 구현하는지는 각자 한 번 찾아보자. (참고로 Django의 라이브러리 중 하나인 django-allauth의 구현 원리에 대해서는 추후 별도의 포스팅으로 다뤄볼 예정이다.)

 

사실 특정 서비스와 카카오 등의 소셜 서비스를 연동하는 가장 쉬운 방법은 사용자가 해당 소셜 서비스의 계정 정보(아이디, 비밀번호 등)를 해당 서비스에게 알려주는 것이다. 그러면 해당 서비스는 해당 사용자의 모든 권한을 가지고 해당 소셜 서비스의 어떠한 기능에도 접근할 수 있기 때문이다. 그러나 이 방법은 너무나도 위험하다. 따라서 OAuth 2.0은 해당 소셜 서비스의 계정 정보를 알려주지 않는 대신 액세스 토큰이라는 것을 발급해주도록 함으로써 해당 사용자가 이용할 수 있는 해당 소셜 서비스의 기능들에 부분적으로만 접근할 수 있는 권한을 부여하게 된다. 물론 이 액세스 토큰의 발급에는 사용자의 동의(허가)가 필요할 것이다. 그렇다면 구체적으로 OAuth 2.0이 액세스 토큰을 어떠한 절차로 발급하는지, 그리고 그 액세스 토큰은 어떠한 역할을 수행하는지 한 번 알아보도록 하자.

 

1. 용어 정리 (Resource Owner, Client, Resource Server)

 

  • Resource Owner : 서비스를 이용하려는 사용자를 말한다.
  • Client : 소셜 서비스와 연동시키고자 하는 서비스를 말한다. 앱이라고도 한다.
  • Resource Server (+ Authorization Server) : 연동하고자 하는 카카오, 페이스북, 구글 등 소셜 서비스의 서버를 말한다. 보통 API를 제공하는 Resource Server와 인증을 담당하는 Authorization Server로 분리되어 있는데, 여기서는 Resource Server 하나로 퉁쳐서 설명을 진행하도록 하겠다.

 

2. Client의 정보를 Resource Server에 등록하기

소셜 서비스와 연동을 시키고자 하는 서비스(앱)는 해당 소셜 서비스의 서버에 등록이 되어 있어야 한다. 카카오, 페이스북, 구글 등 저마다 등록 절차가 조금씩 다르긴 하지만, 다음 세 가지는 공통이다.

 

  1. Client ID 발급 : 해당 서비스(앱)의 고유 번호로, 노출이 되어도 문제없다.
  2. Client Secret 발급 : 해당 서비스(앱)의 비밀번호로, 절대 노출이 되면 안 된다.
  3. Authorized Redirect URL 등록 : 소셜 로그인 후 해당 서비스를 리다이렉트 시킬 주소로, Callback URL이라고도 한다.
    EX. https://client.com/callback

 

3. 액세스 토큰 발급 절차 ★★★

그렇다면 이제 본격적으로 OAuth 2.0이 액세스 토큰을 발급하는 과정를 알아보도록 하자. 여기서는 카카오 로그인을 예시로 그 과정을 설명해보도록 하겠다. 참고로 이는 액세스 토큰이 발급되기까지의 과정일 뿐, 실제로 서비스에서 카카오 로그인을 구현하려면 뒤에 추가적인 과정이 더 필요하다. 여기서 그 과정까지 설명하지는 않으니, 각 웹 어플리케이션 혹은 라이브러리가 그러한 추가적인 과정을 필요로 하는 소셜 로그인을 구체적으로 어떻게 구현하는지는 직접 한 번 알아보기를 권장한다.

 

 

  1. Resource Owner가 [카카오 로그인] 버튼을 클릭하여 카카오 계정 로그인 페이지로 이동한다. 이 버튼의 링크는 Resource Server의 주소이며, GET 파라미터로 Client ID 값, 필요한 권한들, Redirect URL 등이 전달된다.
    EX) https://resource_server.com/login/?
             client_id=1&
             scope=B,C&
             redirect_url=https://client.com/callback
  2. 카카오 계정 로그인 페이지에서 이메일과 비밀번호를 입력하여 로그인한다. 그런데 만약 카카오 계정 로그인을 한 적이 있어서 카카오 계정 세션의 ID가 브라우저에 남아 있다면 이 과정이 생략되고 자동으로 로그인된다.
  3. Resource Server는 GET 파라미터를 통해 전달받은 Client ID 값, 필요한 권한들, Redirect URL 등을 내부에 저장하고 있는 데이터와 비교하여 올바른 요청인지 판단한다.
  4. 그리고 Resource Owner로부터 Client에서 필요한 권한들의 제공에 대한 동의를 구한다. 예를 들어, Resource Owner 카카오 계정의 프로필 정보를 Client가 참조할 수 있도록 할 것인지 물어보게 된다.
  5. Resource Owner가 해당 권한들의 제공에 동의를 하면, Resource Server는 내부에 해당 카카오 계정과 해당 Client의 연결 정보를 저장한다(= 연결 형성). 여기에는 해당 계정이 어떠한 권한들의 제공에 동의를 했는지가 저장된다. 그리고 이곳에 임시 비밀번호 역할을 하는 인증 코드를 발급하여 저장해 둔다.
  6. Resource Server는 Location 헤더에 Redirect URL을 넣어서 리다이렉트 응답을 전달한다. 이때 해당 URL의 GET 파라미터에 방금 발급한 인증 코드를 심어둔다.
    EX) Location : https://client.com/callback?code=3
  7. Resource Owner는 리다이렉트에 의해 Client의 주소로 이동하면서 발급받은 인증 코드를 Client에게 전달한다.
  8. Client는 전달받은 인증 코드를 이용하여 Resource Server에게 액세스 토큰을 요청한다. 이때 자격 증명 정보도 함께 전달한다.
    EX) https://resource_server.com/get_access_token/?
             grant_type=authorization_code&
             code=3&
             client_id=1&
             client_secret=2&
             redirect_url=https://client.com/callback
  9. Resource Server는 전달받은 인증 코드와 자격 증명 정보를 내부에 저장하고 있는 데이터와 비교하여 올바른 요청인지 판단한다. 올바른 요청이라고 판단되면 해당 인증 코드는 즉시 삭제하고 인증 코드가 저장되어 있던 곳에 액세스 토큰을 발급하여 저장해 둔다. 그리고 그 액세스 토큰을 Client에게 응답으로 전달한다.
  10. Client는 전달받은 액세스 토큰을 내부에 저장한다. 이 액세스 토큰은 이제 해당 Resource Server에게 특정 기능을 요청할 때 사용하게 된다. 물론 허용된(= Resource Owner가 동의한) 권한에 해당하는 기능만 요청할 수 있다.

 

※ 리프레시 토큰 (Refresh Token) 참고로 Client가 Resource Server로부터 액세스 토큰을 받을 때 보통 리프레시 토큰도 함께 받는다(아닌 경우도 있다). 이는 액세스 토큰의 갱신을 위해 사용할 수 있는 토큰인데, 일반적으로 액세스 토큰의 유효 기간이 짧기 때문에 필요한 것이다. 액세스 토큰의 유효 기간이 지나서 만료되면 이제 해당 액세스 토큰을 통한 API 요청이 실패하게 되는데, 이때 리프레시 토큰을 통해 간편하게 액세스 토큰을 다시 발급받을 수 있다.

 

※ django-allauth의 소셜 로그인 구현 원리 Django의 라이브러리 중 하나인 django-allauth는 OAuth 2.0 개념을 바탕으로 여러 종류의 소셜 로그인을 구현하였다. 해당 구현 원리에 대해서는 이 포스팅에서 다루며, 이 내용을 이해하기 위해서는 본 포스팅에서 설명하는 OAuth 2.0 개념을 완벽히 이해하고 있어야 한다. 해당 포스팅에서는 본 포스팅에서와 마찬가지로 카카오 로그인을 예시로 설명하지만, 대부분의 소셜 로그인은 원리가 비슷하다는 점을 기억하자.

 

 

 

 

 

 

본 글은 아래 링크의 내용을 참고하여 학습한 내용을 나름대로 정리한 글임을 밝힙니다.

https://opentutorials.org/course/3405