알못이 괜한 아집을 부리다가 쎄게 후드려맞고 정리하는 OAuth
이 내용은 생활코딩 영상을 정리한 내용이며 아래 영상에서 확인할 수 있습니다.
(https://youtu.be/hm2r6LtUbk8)
OAuth는 "클라이언트(내 앱), 로그인을 요청하는 사람, 로그인을 요청받는 서비스" 와의 3자대면이기 때문에 꽤나 복잡하다.
그래서 제대로 이해하는게 많이 어려울 수도 있음. 최소 3-4번은 봐야 이해가 감.
용어부터 정리하고 갑시다.
- Resource Owner : 로그인을 요청하는 사람
- Client : 내가 만든 앱(거의 대부분의 설명에서는 내 앱의 Server, Client의 역할을 통틀어서 설명한다. 그래서 헷갈릴 수도 있으니 유의할 것)
- Resource Server : 로그인을 요청받는 서비스(Google, Kakao, Naver 등..)
위 용어들은 반드시 숙지하도록 하자!
1) 왜 OAuth를 쓰지?
OAuth("Open Authorization")는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.(출처 : 위키피디아)
즉, 개인정보를 내 서비스보다 더 안전한 곳에 맡기고,
그 안전한 곳에서 사용자의 정보를 확인하고 접근할 수 있는 접근권한(토큰)을 발급하도록 하는 것
사용자는 더 안전하고 편리해지고 서비스 개발자는 정보를 관리해야한다는 부담이 줄어들게 된다.
2) 그럼 어떻게 쓰는데?
간단하다. 그림을 보자
- Resource Owner가 Client에게 소셜로그인을 시도했다.
- Client는 Resource Server에게 ID, PW를 달라고 요청한다.
- 그럼 ID,PW를 보내주고 그 값을 저장한다.
- Resource Owner가 내 서비스에다가 로그인 요청할 때마다 Client에서 Resource Server로 직접 로그인하면 됨.
뭔가 이상하지 않음?
구글 로그인 아이디랑 비밀번호를 다른 서비스에 다 보내준다고???
그럼 클라이언트에서 다 까보면 어떡하는데...? 아무리 보안처리가 되었다고 해도 이건 아니지 않나...??
이상한게 맞음
이렇게 하면 큰일남
이 Client를 어떻게 믿을건데?
아무리 클린하고 완벽한 나의 앱이라 해도 Resource Server는 내 앱을 믿지못함.
Resource Server 입장에선 대기업인데 사용자 정보가 아무 앱에서 돌아다니다 해킹이라도 당하면 신뢰도가 급감할거임.
그럼 회사가치는 떨어질거고 주식은 떡락할거고 내 속이 쓰리겠지...
3) 그럼 어떻게 쓰는데?_최종.txt
1. 내 앱 등록하고 Client ID, SECRET값 받기
일단 내 애플리케이션을 Resource Server 즉 구글, 카카오, 네이버 등 소셜로그인 서비스에 등록한다.
등록을 하면 Resource Server에서 Client ID, Secret값을 넘겨준다.
(ID는 외부로 보여도 상관이 없는데, Secret값은 노출 시 재발급을 꼭 해야한다. 꼭!! 꼭!!!!)
2. 로그인 후 동작
-
로그인이 성공하게 되었다면 Client 서비스(앱)에 정보를 제공할건지를 물어본다.
(여기서 정보는 내 소셜서비스의 ID, PW가 아니다. 로그인을 하게 될 경우 제공하는 기초 정보+선택 정보를 뜻함)
승인버튼을 누르게 되면 Resource Server로 넘어간다. -
정보 제공을 '승인'했다는 걸 알려주는 code를 제공한다. 이 코드는 사용자의 정보가 담겨있는 비밀번호 같은 것임
-
Client에서는 code와 함께 이전 단계에서 받았던 Client ID, SECRET을 담아서 다시 Resource Server에게 보내준다.
-
Resource Server에서는 받은 ID, SECRET, code를 1번에서 등록했던 정보와 비교하고 검증한다.
3. Access token 발급받기
-
제대로 검증이 되었다면 Resource Server에서 access token을 발급한다. 발급된 토큰은 파일이나 DB에 저장한다.
-
Client에서 다시 Resource Server로 받은 access token을 이용하여 회원정보를 요청한다.
-
Resource Owner에게 내 앱에서 회원가입/로그인등 요청한 서비스를 성공시켜준다.
이렇게 하면 끝이다.
다만 DRF(Django Rest Framework)에서 JWT와 allauth를 이용하게 될 경우 7번이 매우 헷갈릴 수도 있다.
왜냐하면 내 서비스에서 로그인을 성공하고 돌려받게 되는 코드 이름이 똑같이 access_token이기 때문이다.
사진에서 보이는 첫 번째 access_token은 Resource Server에서 받아온 토큰이고,
두 번째 access_token은 첫 번째 access_token을 이용하여 회원 정보를 조회하고 필요한 정보를 꺼내 내 서비스에 저장 한 다음 가입처리 하게 된 뒤 받게 되는 JWT토큰이다.
카카오에 매우 설명이 잘 되어있으니 아래 사진을 참고하자.
내가 두번째 access_token을 설명한 부분은 빨간 네모를 친 마지막 부분이다.
