본문 바로가기
카테고리 없음

OAuth

by SeoB-P 2022. 6. 12.

간편 로그인

요즘은 어떠한 서비스(웹,앱)에 가입하지 않더라도 다른 서비스회사(구글,카카오,네이버..)의 정보를 이용해 간단하게 로그인 할 수 있는 기능을 제공해 주곤 한다.
이번 토이 프로젝트 진행시에 카카오 로그인을 구현하다가 삽질을 많이 했는데, 그 원리를 알지 못하니 많은 어려움이 있었다.
이게 어떻게 가능한지 각 서비스별로 구체적인 방법은 다 다르지만 대부분 비슷하기 때문에 이번 포스팅에서는
생활코딩님의 예제 + 카카오 디벨로퍼 사이트를 참고해서 진행해 본다.


OAuth

OAuth는 간편 로그인 서비스의 핵심이다.

OAuth("Open Authorization")는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.[1] 이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존,[2] 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다. - 위키백과

OAuth가 생기기 전에는 유저로 부터 아이디와 비밀번호를 입력하게 한다음 그 것을 날 것 그대로 사용을 했다.
하지만, 이는 심각한 보안상의 위험을 내포할 수 있다.
예를들어, 유저로 부터 각종 사이트(구글, 네이버..)의 아이디와 비밀번호를 입력받고 저장을 해두었는데 해커들에게 해킹을 당한다면 한번의 해킹으로 입력해두었던 모든 개인정보가 빼돌려 진다.
또, 정작 서비스에 필요한것이 아닌 권한까지 다 가지고 올 수 있다.
현재 서비스는 일정관리 앱이라고 해보자.
서비스가 필요한 권한은 그저 구글 캘린더에 접근해서 일정을 가지고 오고 싶은데, 아이디 비밀번호를 통해 접속을 하게된다면 불필요한 권한까지 모두 쥐어주게 되어 보안상에 위험을 야기한다.

이러한 문제들을 해결하기 위해 OAuth가 생겼다.

PART 0. 용어

OAuth의 매커니즘을 이해하기전에 용어를 먼저 숙지해보자.

OAuth에는 크게 네가지의 주체가 있다.

Resource Owner

서비스의 사용자이며 Resource Server안 자원의 주인이다.

Client

Resource Server로 부터 정보를 가지고 오고 싶은 서비스 (우리가 만든 서비스)

Resource Server

Google, Facebook과 같이 User가 이미 가입한 서비스이며 필요한 자원을 가지고 있는 서버라고 해서 Resource Server 칭함.

Authorization Server

인증과 관련된 작업을 하는 Server

명확히 구분하자면 Resource Server와 Authorizaition Server를 구분하지만 이번 포스팅에서는 편의를 위해 합쳐서 Resource Server로 칭한다.


PART 1. 등록

Client는 Resource Server를 사용하기 위해서 승인을 받아야하는데 이를 등록 이라고한다.

카카오디벨로퍼 -> 내 어플리케이션 -> 어플리케이션을 추가한다.

Client ID, Client Secret

등록을 하고 나면 Client ID와 Client Secret라는 비밀번호를 발급받게 되는데,
이때, Client Secret은 절대. 외부에 노출되서는 안된다.

Client ID Client Secret

Authorized redirect URI

카카오에서 필수는 아니지만 왼쪽 창에서 카카오 로그인을 클릭하면 Authorized redirect URI를 등록할 수 있다.
Resource Server가 권한을 부여하는 과정에서 authorization Code값을 전달해 주는 데 그 Code를 어떤 URL로 받을지 적는 것이다.
그리고 여기에 등록되어 있지 않은 URI는 모두 무시가 된다.


PART 2. Resource Owner의 승인

등록 과정을 마쳤다면 Resource Server와 Client가 각각 Client ID,sercet, redirect URL를 알고 있게 되었다.
Resource Owner가 서비스를 사용하는 순서대로 살펴보자.

Resource Owner가 Client로 접속을 시도한다.

Client는 권한을 받기위해 ~~로 로그인을 눌러야 한다고 페이지를 보여준다.

각 버튼들은 미리 설정된 Client ID,scope, redirect uri등으로 이루어 져있다.
(scope는 A, B, C, D의 기능이 있을때 서비스에서 필요한 기능만 권한을 주는 것.)

Resource Owner가 위의 주소로 접속.

만약 로그인이 되어 있지 않다면,

Resource Server가 Resource Owner에게 로그인을 요청하는 창을 보여준다.

로그인이 성공적으로 진행이 되었다.

Resource Server는 Client ID와 redirect URL이 정상적인 것인지 한번더 확인 후에, Scope에 맞는 권한을 Client에게 부여 할 것인지 Resource Owner에게 보여준다.

사용자가 이것 마저 동의를 했다.

Resource Server에는 User id 1번이 b,c에 관한 권한을 1번 id를 가진 client 에게 부여했다는 것을 저장한다.


PART 3. Resource Server의 승인

Resource Server가 임시 비밀번호 Authorization Code를 어떻게 활용하고 Client에게 승인을 하는지 알아보자.

Resource Server는 Authorization Code를 Resource Owner에게 전달함.

Location Header가 달린 저 URL은 Resource Owner가 해당 주소로 가게 함.

이로 인해 Client도 Authorization code를 알게 됨.

Client는 Resource Server에 접속함.

Resource Owner를 걸치지 않고 받았던 code,redirect url,client secret를 담아서 Resource Server에 접속함.

Resource Server는 해당 내용들이 맞는지 확인하고 Access Token을 넘겨준다,.


PART 4. Access Token

최종적으로 필요한 Access Token의 발급

각종 검증 절차를 마친 Resource Server는 Access Token을 Client에게 줌.

이제 access Token 4를 가지고 접근을 한다면, user id 1을 가진 사용자의 b와 c에 해당되는 정보를 허용한다.


참고 및 사진 출처
https://opentutorials.org/module/3668 생활코딩
https://developers.kakao.com/ 카카오 디벨로퍼

댓글