소셜 로그인을 이해하기 위해서는 OAuth 의 이해가 필요하다.
OAuth 의 auth 는 authentication 과 authorization 중 무엇을 가르키는 말일까? 정답은 Authorization 이다. 재밌는 점은 Authorization 은 유저와 서비스 사이가 아니라 서비스와 서비스 사이에서 발생하는 authorization 과 연관이 있다는 점이다.
여기에서는 OAuth 를 대략적으로 설명해보고자 한다.
먼저, 보통의 authorization 절차를 복습해보자. 유저가 한 어플리케이션 또는 웹에 로그인 등의 과정을 이용해서 authentication 을 수행하고 access 토큰(jwt)을 발급받는다. 그리고 유저가 토큰과 함께 특정 request(예를 들면 게시판에 글쓰기) 를 보내면 서버는 받은 access 토큰을 복호화 한다. 그 다음, 토큰의 payload 의 담긴 유저의 내용으로 서버 db 에서 해당 유저를 조회하고 해당 유저가 해당 request 를 보내는 자격 또는 권한이 있는 지를 판단한다. 자격이 있으면 요청에 대응하는 응답을 보내고 아니면 권한이 없다는 에러메세지를 보내는 이 과정이 유저와 어플리케이션 사이의 authorization 프로세스이다.
그런데 다음의 상황에서는 authorization 문제가 서비스 사이에서 발생하게 된다.
한 유저(sam)는 '프사기' 라는 어플로 사진을 편집해서 카톡 프로필 사진이나 인스타에 올리고 싶다. 그런데 sam 의 사진 대부분은 구글 드라이브에 저장되어 있다. sam 은 직접 구글 드라이브에서 사진을 자기 기기로 다운받아서 프사기 앱에 업로드 하기보다 프사기 앱에서 직접 구글 드라이브에 접근해서 자기 사진을 프사기 앱으로 바로 가져와서 편집을 하고 싶다.
이때, 프사기 앱은 어떻게 구글 드라이브에 접근해서 sam 의 사진을 가져올 수 있을까?
궁극적으로 프사기 앱은 구글 드라이브에 sam 을 대신해서 sam 의 특정 파일, 여기에서는 sam 의 사진에만 접근할 수 있는 권한이 필요하다. 프사기 앱이 어떻게 이 권한을 얻을 수 있을까? 바로 이 지점에서 OAuth 가 등장한다.
프사기 앱과 구글 드라이브가 모두 OAuth 를 이용하면 다음의 과정이 가능해진다.
구글 드라이브와 프사기 앱 사이에 권한승인이 오고가는 과정을 확인하면 OAuth 가 왜 서비스 사이에서 authorization 을 다루는지 자연스럽게 알 수 있다.
사실 위 과정보다는 조금 더 복잡한 과정을 거친다. 다음 글에서 관련 용어를 정의하면서 조금 더 자세하게 이 과정을 설명하려고 한다.
