✉️ 글쓰기 앞서
toyproject를 진행하던 중 로그인 서비스에 카카오, 구글 오픈 api를 사용해서 로그인을 구현해보기로 했다. 구글 오픈 api를 담당하기로 해서 관련 자료를 찾는데 처음 구현할 때는 꽤나 복잡해보이더라. 특히나 api를 다루는 건 좀 낯설어서 여러 자료들을 보는데 너무 다양한 방식에 점차 어지러워지던 중 직접 필기하면서 과정을 작성해나가니 이해가 됐던 경험을 살려 글을 써보고자 한다. 내가 이해했던 과정을 최대한 더듬어 올려본다.
총 3편으로 정리할 건데, (바탕 및 방향 -> 구현 -> 이해) 과정으로 정리할 생각이다.
OAUTH
로그인 오픈 api를 사용하려다 보면 Oauth라는 걸 많이 볼 수밖에 없다. 따라서 진행되는 과정을 이해하려면 얘를 알고가야한다.
우리는 많은 웹 페이지에서 구글, 카카오, 네이버 등의 여러 플랫폼의 계정을 통해 해당 웹페이지에 대한 인증을 할 수 있었다. 이걸 ouath라 하는 것이다. 외부 서비스에 대한 인증이 해당 서비스에서도 이루어져 원하는 api를 사용할 수 있게 하는 것.
📌 OAUTH란?
간단하게 인증(Authentication)과 권한(Authorization)을 획득하는 것으로 볼 수 있다.은 인증을 위한 개방형 표준 프로토콜입니다.
이 프로토콜에서는 Third-Party 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공한다.
📌 OAUTH.2 인증 과정
위 사진은 인증 과정에 대한 다이어그램이다.
다른건 몰라도 이 사진을 이해해야 구현에 있어서 문제가 없을 거다. 그래서 간단한 예를 들어서 설명을 들어볼까한다.
범죄 영화에선 종종 중요한 물건을 밀매하는 경우가 있다. 만약 우리가 범죄 영화에서 물건을 받아오는 입장(client)라고 해보자. 우리는 물건을 받아오기 위해서 일단 1차 거래자랑 얘기를 나눌 것이다. 1차 거래자는 우선 물건을 가지지 않고 있는 상태이며 유통을 해주는 사람이다.
1차 거래자는 우리에게 물건 거래를 해주는 사람들과 접선시켜주기로 했다. 장소는 1차 거래자가 지정해둔 곳이며 그곳으로 가면 물건 거래를 해줄거라고 한다. 그러면서 장소 정보랑 1차 거래자 자신임을 증명하는 물건을 같이 준다.
1차 거래자가 얘기한 장소로 이동해보자. 이동한 장소에는 2차 거래자가 우리의 신분증과 1차 거래자의 보증했음을 요구하고있다. 우리는 일전에 이 2차 거래자가 속한 회사로부터 거래가능 신분증을 발급했었다. 그 신분증과 1차 거래자임을 증명해주는 물건을 같이 보여준다.
2차 거래자는 이를 확인하고 물건을 제작하는데 시간이 걸리니 나중에 일단 영수증만 가져가라고 한다. 우리는 1차 거래자한테 영수증을 주고 물건을 기다린다. 1차 거래자는 우리에게 받은 영수증으로 2차 거래자한테 물건을 받아와준다.
작성하고보니 참 없어보이지만 위 비유와 OAUTH 인증 과정을 비교해보자. 일단 1차 거래자는 서비스, 2차 거래자(와 그가 속한 회사)는 platform이다.
client는 서비스를 요청하기 위해 access_token을 발급받아야 한다. 위에서 밀매하려는 물건은 access_token인 것이다. 우리는 이 토큰을 발급받기 위해 우선 서비스가 아닌 서비스가 인정하는 플랫폼으로부터 우리임을 인증해야한다.
그러려면 해당 플랫폼에 로그인을 해야하는데 서비스가 정해둔(platform과 약속한) RedirectURI로 이동을 해야한다. 굳이 RedirectURI로 이동하는 이유는 승인되지 않은 URI로 redirect될 경우 authorization code를 중간에 탈취 당할 수 있기 때문이다.
authorization code가 있어야 우리가 원하는 access_token을 발급받을 수 있다. 발급받은 authorization code를 다시 서비스에게 보내준다. 서비스는 받은 authorization code를 통해 platform에게 정보를 받아올 수 있는 access_token을 받아오는 것이다.
.
.
.
위의 비유와 비교하면서 들 수 있는 의문이, "받아온 물건이 access_token이면 그걸로 뭘할 수 있는데?"이라고 생각한다.
📌 ouath를 통해
우리는 받아온 access_token을 통해 해당 플랫폼으로부터 정보를 가져오는 것이 목표다. 처음 로그인 api를 구현할 때 들었던 생각은 "플랫폼으로부터 가져오는 건 뭘까? 우리 서비스에 대한 입장 권한인가?(session과 비슷한 느낌이라고 생각함)" 결론으로는 입장권한을 받아오는 것이 아닌 플랫폼에 저장되어있는, 우리가 원하는 정보를 서비스에게 넘겨받아오는 것이다. 로그인 api는 플랫폼으로부터 정보를 받아 서비스에 맞게 로그인을 해주는 것이다.
이제 슬 틀이 잡힌다. 우리가 로그인 api를 통해 플랫폼에게 받아온 정보는 우리 입맛에 맞게 원하는 정보만 추출해서 회원을 등록해주면 되는 것이다.
📌 참고자료
https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
구현 FLOW
📌 flowchart
위 flowchart와 같은 방식으로 구현하였다. 참고자료에서 구현한 구조와 유사하기 때문에 다음글을 보기 전에 참고 자료를 먼저 확인해보는 것도 좋을 것 같다.
📌 참고자료
https://mslilsunshine.tistory.com/171
📨 글을 마치며
다른 개발자, 개발자 지망생 분들이 올리는 글처럼 프로젝트 관련 문제를 포스팅하듯이 나도 프로젝트에서 경험한 것을 글로 남겨보고 싶었는데 드디어 기회가 왔다. 첫 프로젝트라 부족한 점이 많지만 최대한 곱씹어 넘어가보고자 고민고민하며 글을 작성해봤다.
프로젝트를 경험하고, 글을 남기게 된다면 해보고 싶었던 것은 최대한 직관적이고, 이해하기 쉽게 만들어보고 싶었다. 단순히 내가 기억하기 위해서가 아닌 어딘가 존재하는 또 다른 내가 덜 고생했으면 하는 마음으로 글을 작성했다. 이런 부분이 어려웠지, 저런 부분이 이해가 안됐지, 등등..
그래서 다소 이해를 위해 추가한 부분이 주관적인 것 같기도 하다. 말도 안되는 비유를 드는 등...(범죄영화가 어쩌고..) 자주 쓰다보면 나아지겠지 싶다...
