프로젝트 지식(4) - 소셜로그인 기초 지식
소셜로그인
현재 하는 프로젝트의 첫 과제가 소셜 로그인인데 그냥 로그인과 다를 바 없다고 생각하다가 큰 코 다치고 있다. 장고에서 템플릿으로 프론트까지 맡아서 하면 어렵지는 않지만 SPA(react)와 같이 통신을 하려고 하니 굉장히 복잡해지는 거 같다. 따라서 소셜 로그인이 구동되는 원리와 과정을 살펴보면서 천천히 구현을 해보고자 한다.
아마 이 포스트에는 같은 내용을 여러번 반복하여 설명할 것이다. 나한테는 너무 어려운 내용이라 이해될 때까지 여러 자료를 살피면서 완벽히 이해해 볼 것이다.
OAuth
소셜 로그인을 구현하기 위해서는 그 근간이 되는 OAuth에 대한 개념을 정확히 이해할 필요가 있다.
OAuth는 내가 만든 서비스에서 다른 서비스를 사용하기 위해 AccessToken이라는 일종의 비밀번호를 이용한다. 다시 말해 OAuth는 다른 서비스로부터 AccessToken을 얻어내 해당 서비스의 일부 기능을 이용할 수 있는 것이다.
OAuth의 참여자
- Resource Server: 제어하고자 하는 자원을 갖고 있는 서버로 Google, Kakao, Naver 등이 있다.
+ 인증과 관련된 처리를 전담하는 서버인 Authorization Server도 있지만 이는 Resource Server에 포함시킬 수 있을 것 같다. - Client: Resource Server에 접속해서 정보를 가져가는 클라이언트(웹 어플리케이션)이다.
- Resource Owner: 자원의 소유자로 Client가 제공하는 서비스를 통해 로그인하는 실제 유저를 말한다.
OAuth 과정
① Resource Server에 Client 등록
Client가 Resource Server를 이용하기 위해서는 사전승인을 받아야 하는데 이때 중요한 것이 3가지 요소가 있다.
- Client ID: 내가 만들고 있는 어플리케이션을 구분하는 식별자로 public key이기 때문에 공개되어도 된다.
- Client Secret: Client ID에 대한 비밀번호로 절대 공개해서는 안되는 secret key이다.
- Authorized redirect URIs: Authorization Code를 전달받을 주소로 Client Secret를 확인한 후 redirect할 url 주소이다. 로그인이 완료되면 token을 보내는 url이라고 할 수 있다.
위의 요소가 모두 일치해야 OAuth가 성공적으로 인증된다.
아래의 구글 OAuth 2.0 클라이언트 ID 서비스를 통해 위의 요소들을 살펴보자.
이렇게 되면 Resource Server로부터 설정해둔 Authorized redirect URIs에 Authorization Code와 Access Token을 부여받는다.
② Resource Owner의 승인
그 전에 다른 세세한 과정들이 있는데 이를 한 번 살펴보자. Resource Owner가 Resource Server에게 Client의 접근을 승인한다는 것을 알려줘야 하는데, 그 과정을 천천히 살펴보자.
- Resource Owner가 Resource Server에게 승인 요청을 보낸다.
- Resource Server가 Resource Owner에게 Authorization Code를 보낸다.
- Resource Owner가 Client에게 Authorization Code를 보낸다.
- Client는 Client ID, Client Secret, Redirect URL, Authorization Code 네 가지를 모두 갖고 있는 상태이다.
③ Resource Server의 승인
- 위 네 가지 정보를 Resource Server에 보낸다. 특히 Client ID, Client Secret, Authorization Code 세 가지는 꼭 보내야 한다.
- Resource Server는 네 가지 정보가 모두 일치하는지 확인한다.
- 하나라도 불일치 할 경우 OAuth 로그인은 실패한다.
- 모두 일치하면 Access Token을 발급한다.
④ Access Token 발급
발급 받은 Access Token을 통해서 Resource Server의 기능을 이용할 수 있다.
⑤ Refresh Token 발급
토큰을 다시 발급받을 때마다 사용자에게 인증과정을 처음부터 밟도록 하는 것은 적합하지 않기 때문에 Access token의 수명이 다했을 때 새로운 access token을 발급 받는 방법이 refresh token이다.
Access Token은 주로 세션에 저장하고, Refresh Token은 중요하기 때문에 DB에 저장한다.
소셜로그인 과정 다시 정리
위의 예시로는 조금 설명이 부족한 것 같아 다시 한 번 소셜 로그인 절차를 정리해보려 한다.
1. 소셜 서비스에 접근하기 위해 동록
홈페이지에 등록을 완료하면 Client id(식별 ID), Client secret(식별 비밀번호), Authorized Redirect URL(인증코드(Authorized Code)를 전달해줄 경로)
2. 소셜 로그인 버튼 클릭
로그인을 한다면 사용자가 타고 들어온 서비스에 담겨진 redirect url을 비교하여 같은 url을 가지고 있다면 사용자에게 로그인을 허용하는지에 대한 메세지를 띄움.
서비스 제공자는 그 응답에 담긴, 사용자의 소셜 로그인에 대한 데이터를 소셜서비스로 부터 받는다. client id, scope…
3. 사용자 승인 후 소셜 서비스로부터 승인을 받아야 함.
Authorization Code를 소셜서비스가 서비스 사용자에게 제공하는 응답의 header에 location: https://[redirect URL]?code=[Authorization Code]’이라는 값을 주어 redirect하도록 한다.
location으로 인해, 서비스 사용자는 해당 주소로 redirect 되는 것이다.
따라서, 서비스 제공자는 redirect로 넘어온 url뒤의 params 형태로 담긴 Authorization Code를 알게된다.
서비스 제공자가 소셜 서비스로 접속할 때 가지고 간 위의 주소 링크에서 Authorizaion code와 clientID, client secret, redirect URL이 일치하면 Access Token을 발급한다.
백엔드와 프론트엔드에서의 동작
위의 예시로는 백엔드와 프론트엔드 각각에서 어떠한 역할을 하는지 알기가 어려워 이를 정리하고자 한다. 아래의 그림이 이 둘의 상호과정을 잘 설명해주고 있다.
그런데 내가 찾아보면서 이 과정과는 살짝 다른 과정으로 통신이 이루어지는 것을 알았다. 내가 이해한 것이 정확히 맞는지는 모르겠지만 여기서는 4번에서 프론트가 인가코드를 백엔드에게 전달하면 이를 백엔드가 소셜 로그인 사이트(리소스 서버)에 전달해 엑세스 토큰을 받는 것으로 되어있다.
하지만 많은 과정이 프론트엔드가 엑세스 토큰까지 받고 이 엑세스 토큰을 백엔드에게 전달하고, 백엔드는 프론트엔드에게 받은 엑세스 토큰을 통해 리소스 서버에게 유저의 정보를 전달받는다.
그리고 이 정보를 바탕으로 유저 정보가 데이터베이스에 있으면 토큰과 함께 프론트에게 다시 정보를 전달해주고, 없으면 DB에 정보를 저장하고 그 정보를 토대로 토큰을 발행한 뒤 로그인 처리를 하면 된다.
Leave a comment