Oauth를 배워서 남주자 - gae-jang-mo/app GitHub Wiki

Oauth를 쓰는 이유

우리의 서비스에서 사용자의 구글 캘린더, 페이스북 등과 같은 곳에 접근해 데이터를 기록하거나 가져오는 것을 구현하고 싶다.
이를 위한 1차원적 인 방법은 그 해당 서비스(구글캘린더, 페이스북)의 비밀번호 아이디를 가져오는 것이다.
그런데 그러면 내가 그 서비스의 아이디,비번도 관리해야 하고 보안 문제가 있을 수 있다. 이를 해결 하기 위해 Oauth를 도입하였다.
직접 아이디, 비밀번호를 가져오는 대신 AccessToken을 외부 서비스로 부터 발급 받아 저장함.

Oauth 용어(2.0을 기준으로)

Resource Server: 우리가 제어하고자 하는 자원을 가지고 있는 서버(Github, facebook...)

Authorization Server: 인증을 처리하는 서버

Resource Owner: 유저

Client: 우리의 서비스

등록

Client가 Resource Server를 이용하기 위해서는 사전에 승인을 받아야 함. (서비스마다 차이가 있음) Client ID는 우리가 만들고 있는 애플리케이션(Client)의 식별자
Client Secret은 그것에 대한 비밀번호(외부 노출X)
Authorized redirect URIs. 권한을 부여하는 과정에서 Authorized Code를 주는데 그것을 주는 주소

Resource Owner의 승인

ResourceServer의 B, C 기능을 쓴다 가정하면 저런 링크를 만들어 주면 됨.
Resource Owner가 링크로 접속하면 현재 로그인 하지 않으면 로그인 화면을 띄워줌.
로그인 한 후 Client ID가 현재 존재하고 있는지, redirectUrl이 일치하는지 확인함.
그 후 권한부여 여부를 확인함. 확인 후 Resource Server가 user Id와 scope 저장.

Resource Server의 승인

autorization code를 Resource Server가 생성하고 Resource Owner를 리다이렉트 시킴.
Client는 Resource Owner에게 code를 자동으로 전달함.

Client는 authriztion code와 client id, secet을 Resource Server에 전송함.
이것이 완전히 일치하는지 Resource Server가 확인하고 Access Token을 발급함.

Access Token 발급

Authorization code를 삭제함 (양 쪽 모두)
AccessToken을 client로 넘김.

accessToken을 Client에 저장하고 그것으로 ResourceServer와 통신

googleapi.com/calender/어쩌구의 url로 헤더 안에 accessToken을 넣는 방식으로 통신

Refresh Token

AccessToken은 수명이 있음. 표준 상 Refresh token은 옵션(https://tools.ietf.org/html/rfc6749)

방식은 플랙폼마다 다름. 스펙은 동일.