생활코딩 OAuth 2.0 강의를 듣고 정리한 내용입니다.
시작
흔히들 어떤 서비스를 사용하면서 구글, 카카오, 페이스북 등의 유저 정보를 통해 로그인, 혹은 회원가입을 이용한 경험들이 있을 것이다. 소셜 로그인이라 불리우는 이것은 내가 제공하는 서비스에서 유저들이 기존의 다른 서비스에서 가입했던 유저 정보들을 통해 나의 서비스도 이용할 수 있게끔 하는 아주 편리한 기능이다. 이 때 우리는 다른 서비스의 API에 접근하기 위해서 사용자로부터 권한을 위임 받아야 하는데 가장 단순하면서도 강력한 방법은 ID와 패스워드를 저장하고 있는 것이다. 그러나 이것은 굉장히 큰 위험성을 가지고 있다. 이러한 위험성을 감소시키면서 해당 권한을 위임받기 위해 고안된 기술이 OAuth이다.
OAuth의 3개의 주체
Resource Server - 자원을 가진 서버로 위의 예시는 구글, 카카오, 페이스북 등이 해당된다.
Resource Owner - 유저 정보 자원의 소유자인 유저를 뜻한다.
Client - 정보를 가져가는 주체로 내 서비스에 해당된다.(Authorization Server) - 인증 관련된 처리를 전담하는 서버이다. 공식 매뉴얼에서는 구분해서 제시한다. 이 강의에서는 Resource Server에 포함시킨다.
Resource Server에 등록하기
Client(내 서비스)가 Resource Server에 등록을 미리 해두어야만 사용할 수 있다. Client ID(만들고 있는 앱의 식별자), Client Secret(식별자에 대한 비밀번호), Authorized redirect URIs(권한을 부여하는 과정에서 Authorization Code를 전달할 주소)
아래 이미지는 카카오톡 API를 사용하기 위해 등록하는 화면을 예시로 가지고 왔다.
Resource Owner의 승인
https://resource.server/?client_id=1&scope=B,C&redirect_url=https://client/callback
client_id : 사전 등록 시 입력한 앱의 식별자
scope : 접근하고자 하는 서비스
redirect_url : 사전 등록 시 입력한 Authorized redirect URIs
위와 같은 형식의 주소로 Owner가 접속을 시도하고 해당 정보들이 미리 등록된 정보와 동일하다면 요청이 들어온 scope에 대한 권한을 허용할 것인지에 대한 메세지를 보여준다. Owner가 허용한다고 하면 Resource Server는 해당 허용 정보를 저장한다.
예시를 들어 설명하면 다른 서비스에서 카카오 소셜 로그인을 시도한 경우 첫 로그인 시도라면 어떠한 정보를 제공할 것인지 동의하는 창을 본 적이 있을 것이다. 소셜 로그인의 입력창에 아이디, 패스워드를 입력하고 로그인 한 것이 위 형식의 주소로 요청을 보낸 것이고, 그 후 카카오 서버로부터 어떤 항목을 동의할 것인지 선택하는 화면 후 보내는 것이 Owner가 허용하는 순간이라 생각하면 될 것 같다.
Resource Server의 승인
Location : https://client/callback?code=3
임시 비밀번호를 먼저 발급해서 유저의 브라우저에게 응답을 보낼 때 해당 정보를 헤더에 담아서 보내게 된다. 그렇게 되면 유저가 인식하지 못한 순간에 위 사전 등록 시 입력한 redirect url로 이동하게 된다. 이 때 Client는 발급된 임시 비밀번호를 받게 되는데 code가 임시 비밀번호에 해당한다. 이제 Client는 Authorization Code를 가지고 Resource Server에게 아래와 같은 형식으로 직접 요청을 보내게 된다.
https://resource.server/token?grant_type=authorization_code&code=3&redirect_uri=https://client/callback&client_id=1&client_secret=2
이제 Resource Server는 들어온 요청 정보를 가지고 일치 여부를 확인한 후 AccessToken을 발급해준다. 이 때 Authorization Code를 삭제한다. 이 후의 불필요한 인증을 하지 않기 위함이다.
Refresh Token
일반적으로 AccessToken은 수명이 존재한다. 해당 수명이 끝나면 기존의 AccessToken을 사용할 수 없다. 이 때 유저에게 다시 권한이임을 받는 방법이 있지만 RefreshToken을 이용해서 해당 과정을 거치지 않을 수 있다.(물론 해당 과정이 필수인 경우도 있다.)
이 RefreshToken은 위의 AccessToken을 발급 받을 때 함께 발급받아서 Client의 데이터베이스에 저장하였다가 AccessToken이 만료되었을 경우 RefreshToken을 Resource Server에 권한을 요청하면 AccessToken을 다시 발급받을 수 있게 된다. 이 때 AccessToken과 함께 RefreshToken도 갱신되는 경우도 있고 아닌 경우도 있다. 이는 서비스별로 차이를 보인다.
끝
카카오톡 소셜 로그인 기능을 위코드 프로젝트를 통해 구현해본 경험은 있지만 그 베이스가 되는 OAuth에 대해 조금은 추가적인 공부를 해보았다. 예시 스크린샷을 카카오톡의 것을 가져왔지만 구글, 페이스북 등도 기본적인 요청, 응답 과정은 크게 벗어나지 않을 것이라 생각된다. 실제로 구현을 하게 된다면 각 서비스에서 제공하는 개발자문서를 확인해보아야 하지만 이러한 베이스를 알고 한다면 보다 쉬워질 것이라 생각한다.
