1. OAuth 란?
- oauth는 사용자, 서비스A, 서비스B 가 서로 상호작용하며 서로를 신뢰하기 위해 고안된 기술이다.
2. OAuth 가 필요한 경우
** 상황 **
사용자가 서비스A에 접속해서 글을 조회, 등록했을 때, 서비스A가 사용자를 대신해서 구글 캘린더의 일정을 등록해주거나, 페이스북에 글을 조회했음을 공유해주는 처리를 하고 싶으면 사용자로 부터 사용자가 사용하고 있는 서비스(구글, 페이스북)에 접근할 수 있도록 허가를 받아야 한다.
** OAuth 방식을 사용하지 않는다면? **
가장 쉬운 방법은 사용자로부터 구글, 페이스북 아이디, 패스워드를 전달받아서 저장하여 사용하는 것이다. 하지만 사용자와 구글, 페이스북의 입장에서 신뢰성이 부족한 서비스A에게 개인 리소스를 맡기고 싶지 않을 것이며 서비스A도 해당 정보를 유실했을 경우의 책임이 커진다.
** OAuth 방식을 사용한다면? **
훨씬 더 안전하고 서비스A와 구글, 페이스북 같은 타 서비스를 이용할 수 있다. 구글, 페이스북 서비스가 access token을 발급한다. 또한 사용자의 구글, 페이스북 서비스의 모든 기능에 대한 권한이 아니라 서비스가 필요한 권한만 담아 발급한다. 서비스A가 위처럼 OAuth 방식으로 토큰을 획득하고 이 토큰을 통해 구글, 페이스북에 접근해서 데이터를 가져오고 수정할 수 있다.
3. OAuth 에서 핵심 관계 역할별 용어
1) Resource Owner (사용자)
2) Resource Server (구글, 페이스북처럼 사용자의 데이터를 가지고 있는 서버)
3) ClientServer (서비스A)
4) Authorization Server (인증관련 처리 전담하는 서버)
// 공식 메뉴얼에서는 Resource Server, Authorization Server 구분하지만 이 포스트에서는 간략하게 통합한다.
4. 등록 방법
** 등록이란? **
클라이언트 서버가 리소스 서버를 이용하기 위해서는 리소스 서버로부터 승인을 받아야 하는데 이를 등록이라 한다.
** 등록에 필요한 요소 **
1) 클라이언트 ID : 클라이언트 서버임을 식별하는 고유번호 (외부 노출되도 괜찮음)
2) 클라이언트 Secret : 클라이언트 서버임을 식별하는 비밀번호 (외부 노출되면 안됨)
3) Authorized redirect URls : 리소스 서버가 권한을 부여하는 과정에서 authorization code값을 주는데, 그 때 전달될 주소이다. 만약 이 주소가 아닌 다른 주소에서 요청이 오면 리소스 서버는 거부한다.
- 등록을 하면 클라이언트 서버와 리소스 서버는 클라이언트 ID, Secret 정보를 가지게 된다.
- 클라이언트 서버는 리다이렉트 Url을 준비해두어야 한다.
5. Resource Ownser 의 승인
- 리소스 서버가 A, B, C, D 기능을 제공한다고 할 때, 클라이언트 서버가 B, C 기능만 필요로 하는 상황이다.
- 리소스 오너가 클라이언트 서버에 접속해서 리소스 서버의 기능을 이용하려고 하면, 클라이언트 서버에게 리소스 서버의 소셜 로그인 버튼이 담긴 페이지를 보여준다. 해당 버튼의 링크는 https://resource.server?client_id=1&scope=B,C&redirect_url=https://client/callback 이다.
- 리소스 오너가 위 링크로 접속하게 되면, 리소스 서버는 리소스 오너가 현재 로그인이 되어있는지 여부를 검사한다. 로그인이 안되어 있으면 로그인 페이지를 제공하고, 로그인이 완료되어 있다면 리소스 서버는 위 링크의 client_id, 리다이렉트 url 값과 자신이 가지고 있는 값이 같은 지 확인한다.
- 리다이렉트 url과 다르면 작업을 끝내고, 같다면 리소스오너에게 scope에 해당하는 정보를 허용할지를 묻는 동의 페이지를 리소스 오너에게 제공한다. 그러면 리소스 서버는 '리소스 오너 (uid=1)는 스코프 b, c 에 동의하였다.' 란 정보를 DB 에 저장한다.
6. Resource Server의 승인
- 리소스 서버는 authorization code : 3 (임시비밀번호)를 리다이렉트 하라는 링크와 함께 리소스 오너에게 전송한다.
- Location 헤더 값에 의해서 리소스 오너의 웹브라우저는 클라이언트 서버로 리다이렉트 된다. code=3 파라미터에 의해 클라이언트 서버 authorization code를 가지게 된다.
- 클라이언트 서버는 리소스 오너를 거치지 않고 리소스 서버로 직접 접속하게 된다.
- 리소스 서버는 클라이언트 서버의 요청 url 중 code=3을 보고 자신의 authorization code = 3을 찾아 클라이언트 ID, Secret이 일치하는지 체크한다.
- 모두 일치한다면 access token을 발급한다.
7. 액세스 토큰 발급
- 리소스 서버는 authorization code로 이미 인증을 마쳤기 때문에 클라이언트 서버, 리소스 서버의 authorization code 정보를 제거한다. (그래야 다음엔 인증을 하지 않는다.)
- 리소스 서버는 accessToken=4를 생성하고, 클라이언트 서버에게 토큰을 준다. 클라이언트 서버는 이 토큰을 내부적으로 저장한다.
- 클라이언트 서버가 accessToken=4로 접근하면, 리소스 서버는 이 토큰 4를 보고, uid=1이고 B, C 권한이 열려있는 사용자의 토큰임을 알게되어 동작한다.
8. API 호출
- 클라이언트 서버는 리소스 서버의 기능을 이용하기 위해 리소스 서버의 API를 호출한다.
- 단, 인증이 필요한 API 에 대해서는 access token을 요청에 담아 보낸다.
- 토큰을 요청에 담아보내는 방식은 리소스 서버마다 다르다. 헤더(Authorization) 값이 많이 쓰인다.
- curl - H "Authoization:Barier 토큰" api링크
9. refresh token
- 액세스 토큰을 일반적으로 1, 2시간, 길게는 60일까지 수명이 있다.
- 액세스 토큰을 다시 발급할 때마다 사용자에게 그 과정을 다시 거치지 않고 손쉽게 발급받는 방법이 refresh token이다.
- oauth 2.0 rfc 6749 - refresh token 인터넷 표준문서
a) 클라이언트 서버가 authorization code를 authorization 서버에 보낸다.
b) authorization 서버가 액세스 토큰, 리프레시 토큰을 클라이언트 서버에게 리턴한다.
c) 클라이언트 서버가 리소스 서버의 액세스 토큰을 담아 api를 호출한다.
d) 리소스 서버는 액세스 토큰이 유효한 경우에 보호된 리소스 서버의 기능/데이터를 리턴한다.
e) 클라이언트 서버가 리소스 서버의 액세스 토큰을 담아 api를 호출한다.
f) 리소스 서버는 액세스 토큰이 유효하지 않은 경우에 invalid token error을 리턴한다. (액세스 토큰 수명 종료를 의미)
g) 클라이언트 서버는 리프레시 토큰을 담아 authorization 서버에 요청을 보낸다.
h) authorization 서버가 액세스 토큰, 리프레시 토큰을 클라이언트 서버에게 리턴한다. (재발급) - 경우에 따라 리프레시 토큰은 새로 발급되는 경우도 있고, 액세스토큰만 계속 갱신되는 경우도 있다. 리소스 서버마다 다르다.(refreshing)
참고 : https://www.youtube.com/watch?v=XpBf7ZiT_do&list=PLXB5p_g4hZpMgHGZ4iMefHl_6D51sEhaT&index=9