프로젝트에 소셜로그인을 도입하기로 했다.
언젠가는.. 공부해야했던 일..😇 이참에 자주 사용할만한 소셜로그인들을 도입하면서 공부해보기로 했다.
프로젝트에는 google, kakao, naver, github 정도를 구현 할 생각이지만, 다른 소셜로그인 기능을 구현하게 되면 추후에 추가해서 포스팅 하도록 하겠다.
해당 포스팅의 OAuth는 2.0을 기준으로 설명하고 있다.
소셜로그인을 구현하려는 당신. OAuth가 무엇인지 알고 있읍니까? 🙋♀️
OAuth가 무엇인지 아는 당신! 소셜로그인 구현이 쉽다고 생각하는 당신! 좋겠다..
그렇다. 나는 몰랐다. 소셜로그인이 작동하는 원리에 대해 아예 모르고 있었는데 OAuth에 대해 공부하면서 득도 수준으로 OAuth를 낱낱히.. 공부했다..
구현을 하는것도 좋지만 어떤 원리이기에 이렇게 구현해야하는지 알고 하는 것이 좋으니 함께 알아보자!🔥
📚 OAuth의 정의
위키백과에서는 OAuth를 다음과 같이 정의하고 있다.
OAuth("Open Authorization")는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
위의 정의가 이해가 되지 않아도 괜찮다. 우선 가정을 해보자.
만약 OAuth가 없다면 소셜로그인을 어떻게 구현할 수 있을까? 유저는 서비스에 소셜 서비스에 대한 아이디와 비밀번호를 제공하고, 해당 서비스는 그것을 기억했다가 소셜로그인에 접근하는 방법이 좋을까? 사실 이러한 방법은 보안상의 문제가 충분히 발생할 수 있기 때문에 좋지 못하다. 유저 또한 신뢰할 수 없는 서비스에 아이디와 비밀번호를 제공하기가 껄끄러울 것이다.😅
지금의 소셜로그인 방식은 유저가 ID와 비밀번호를 입력했을 시에 accessToken을 소셜 플랫폼에서 제공하고 우리는 해당 Token을 OAuth를 통해 획득해서 데이터를 가져오고, 입력, 생성, 수정, 삭제 하는 등의 업무를 진행할 수 있게 된다. OAuth는 비단 로그인 뿐만 아니라 요청한 서비스에 접근해서 사용이 가능하다!
👥 OAuth의 구성
OAuth에 등장하는 구성원들의 용어를 정의하자면 다음과 같다.
👤 Resource Server:
우리가 제어하고자 하는 자원을 가지고 있는 사람
데이터를 가지고 있는 서버
access token을 발급해준다.
예) 구글, 페이스북, 네이버, 카카오 ...
👤 Authorization Server:
인증과 관련된 처리를 전담하는 서버
인가 코드를 발급해준다.
🗣 Resource Owner:
자원의 소유자
즉, 소셜로그인을 하려고 하는 유저를 일컫는다.
🗣 Client
Resource Server에 접속해서 정보를 가지고 가는 Client
즉, 소셜로그인을 사용하려고 하는 플랫폼을 일컫는다.
🔥 OAuth의 인증과정 예시
PAYCO에 OAuth에 대한 인증과정 설명이 아주 자세하게 잘되어있어서 이미지를 가져왔다.
🔁 OAuth 인증과정
🔁 OAuth 프로세스
우선 플랫폼 즉, Client에서 소셜로그인 등등의 OAuth 관련 인증을 요청하면 Resource Server와 Authorization Server에서 일련의 과정을 거친 다음 Access Token을 발급해준다. 그러면 Client에서는 해당 Access Token을 저장한 후 인증을 완료한다.
이후 Access Token을 이용해서 서비스를 요청하면 API를 호출하여 해당 Token이 유효할 시 필요로 했던 서비스를 유저에게 제공해준다.
🔥 OAuth의 인증과정 상세
자 아직도 무슨 말인지 모르겠는 사람들을 위해 열심히 그림을 그려왔다...!
(혹시 틀린 내용이 있다면 댓글로 정정 부탁드립니다!)
모든 과정은 이미 OAuth를 요청할 서비스에 어플리케이션을 등록한 이후에 시행되어야한다.
- 유저는 Client Application의 로그인 버튼을 눌러 로그인을 요청한다.
- 공식문서에 따른 인가코드 발급 api 뒤에 요구하는 정보를 붙여 인가코드를 요청해준다.
- OAuth를 제공하는 서비스는 어플리케이션을 등록할 때 함께 등록해준 redirect URI 뒤에 code= ~~ 형식으로 인가코드를 발급해준다.
- 프론트는 code= 뒤의 인가코드만 예쁘게 썰어서 백으로 전달해준다.
- 백엔드에서는 OAuth를 제공하는 서비스에 공식문서에 따른 토큰 발급 api뒤에 요구하는 정보와 프론트에서 전해준 인가코드를 붙여 OAuth에서 제공하는 서비스에 접근할 수 있는 access_token을 요청한다.
- 이후, OAuth를 제공하는 서비스의 access_token을 활용해 유저의 정보들을 가져오고, 해당 정보들을 DB에 저장해준 뒤 Client Application에서 사용할 access_token을 발급한다.
여기서 유의할 점은 5번의 access_token은 OAuth를 제공하는 서비스에 접근 할 access_token이고, 6번의 access_token은 우리의 서비스에서 발급하는 access_token이다. 6번의 의견은 백엔드 선생님의 의견인데 아마 이렇게 하는 이유는 OAuth에서 제공하는 access_token을 계속 활용해서 유저의 정보들을 가져오는 api를 호출해도 상관없지만 DB 등에 저장한 뒤 서버 단에서 정보를 갈무리하고 클라이언트에 던져주기 위해서인 것 같다. - Client Application에서 사용할 access_token을 프론트에 던져준다.
이렇게 말로 하는 것 보다 직접 구현해본다면 조금 더 와닿을 것이다. (나도 그랬다!)
다음에는 구글부터 어떻게 소셜로그인을 구현하는지 알아보자.✊
➕ 참고
