생활 코딩의 WEB2 - OAuth 2.0 강의를 들으며 정리한 자료입니다.
강의 영상은 아래 페이지에서 확인하실 수 있습니다.
https://opentutorials.org/course/3405
WEB2 - OAuth 2.0 - 생활코딩
수업소개 사용자가 가입된 서비스의 API에 접근하기 위해서는 사용자로부터 권한을 위임 받아야 합니다. 이 때 사용자의 패스워드 없이도 권한을 위임 받을 수 있는 방법이 필요합니다. 이를 위
opentutorials.org
1. 수업 소개
3개의 참여자
Mine: 나의 서비스
User: 나의 서비스 사용자
Their: 나의 서비스가 연동하고자 하는 그들의 서비스. Ex) 구글, 페이스북, 트위터
User가 Mine에 글을 쓰면, Their인 그들에 정보를 입력함.
user로부터 their의 서비스에 접근할 수 있도록 허가를 받아야 함.
User가 Their에 id, password가 있을 텐데 user에게 그것을 받아서 우리가 their에 접근하는 것.
근데 매우 위험함. 사용자가 자신의 id, password를 처음 보는 서비스에 맡기기는 위험하다.
우리도 정보 관리하기 어려움.
이것을 해결해주는 게 OAuth. 안전하다.
Mine과 Their의 상호작용 가능.
이제 User에 요청으로 Their가 Mine에게 accessToken을 발급함. 이것의 장점: id, 비번이 아니다 + Their의 기능 중 일부만 허용함.
우리가 OAuth를 통해서 accessToken을 획득하고, accessToken을 통해서 Their에 접근할 수 있음.
회원의 id, password를 받지 않고 로그인하는 기술을 많이 본 적이 있을 것이다.
Federated identity(연합 식별자)라고 한다. Login with Google 같은 거. 이것의 기반 기술이 OAuth.
OAuth를 통해서 access token을 얻는 원리를 알아볼 것이다.
2. 역할
우리가 만든 서비스 Mine
사용자 User
유저는 Their 서비스에 회원가입 되어있다.
Their -> 자원을 갖고 있는 서버. Resource Server
User -> 자원의 소유자. Resource Owner
Mine -> 우리의 서비스. 리소스 서버에 접속해서 자원 가져감. Client
Authorization Server도 있다.
Resource Server가 데이터를 가지고 있는 서버라면, Authorization Server는 인증과 관련된 처리를 전담하는 서버. 우리는 이 둘을 합쳐서 Resource Server라고 고려하는 것인데, 공식 매뉴얼에는 나뉘어있다.
3. 등록
Client가 Resource Server를 이용하기 위해서는 Resource Server의 승인을 사전에 받아야 한다.
이것이 등록이다(register).
서비스마다 등록하는 방법이 다른데, Client ID, Client Secret, Authorized redirect URIs 3가지를 공통으로 받음.
(예시를 보니 정확히는 우리가 Authorized redirect URIs를 입력하고, 리소스 서버에서 Client ID, Client Secret을 전달해주는 방식인 듯)
Client ID는 서비스의 식별자, Secret은 비밀번호. ID는 노출되어도 되지만 Secret은 노출되면 절대 안 됨.
Authorized redirect URIs는 리소스 서버가 권한을 부여하는 과정에서 우리에게 Authorized 코드를 전달할 텐데, 이 주소로 전달해달라고 알리는 것이다.
리소스 서버는 다른 주소에서 요청하면 무시한다.
현실의 OAuth 등록 예제 살펴봄.
4. Resource Owner의 승인: 인증받는 과정
등록하면 리소스 서버와 클라이언트는 양쪽 다 client id, client secret, redirect uri를 알게 됨.
클라이언트는 redirect URI에 해당하는 페이지를 준비해놓고 있어야 함.
리소스 서버가 가진 기능이 A, B, C, D 4개라고 했을 때 클라이언트가 B, C만 필요하다고 가정해보자.
유저(리소스 오너)는 Client에 접속함. 우리가 리소스 서버를 사용해야 한다면,
Ex) 페이스북에 글 게시, 구글 캘린더에 날자 게시.
리소스 오너에게 페이스북으로 로그인하는 화면을 보여줘야 함. 인증받기 위해서. 사용자가 동의해야 그다음 과정으로 진행할 수 있음.
로그인하는 버튼을 클릭하면 리소스 오너가 동의하는 것.
그 버튼은 사실 별것이 아닌데, 링크를 만들어주면 된다.
링크는 리소스 서버, 클라이언트 id, scope, redirect uri 정보를 포함하면 된다.
Scope는 리소스 서버(구글 등)가 정해준 형식으로 보내면 됨.
리소스 오너가 리소스 서버로 저 주소로 접속하게 되면, 리소스 서버가 리소스 오너가 로그인되어있는지 확인하고 로그인 안 되어있으면 로그인하라는 화면을 보여줌.
리소스 오너가 로그인에 성공하면 그때서야 리소스 서버는 client id와 같은 client id가 있는지 확인함. 거기 redirect uri와 접속 시도 요청 redirect uri가 같은지 확인하고 다르면 작업을 끝냄.
같으면 리소스 오너에게 scope에 해당하는 권한을 client에게 줄 것인지 확인하는 메시지 전송함.
우리가 자주 보는 화면. ~~ 기능을 ~ 클라이언트가 요청하고 있는데 허용할 것인지 물어봄
아래 사진(화질이!!!...)과 같다.
리소스 오너가 허용하면 리소스 서버는 리소스 오너의 user id에 대해 scope B, C 작업을 허용한다는 정보를 저장하고 있음.
사용자로부터 리소스 서버에 접속하는 것에 대한 동의를 거치는 작업을 거침.
실제로 리소스 서버가 인증을 어떻게 처리하는지 다음 강의에서 살펴보자.
5. Resource Server의 승인
리소스 서버가 승인하기 위해서 바로 access token을 발급하지 않고, 기능을 한 번 더 거친다.
그때 사용하는 임시 비밀번호가 authorization code이다. 리소스 서버는 이 authorization code를 리소스 오너에게 전달함. 응답 시 헤더에 Location을 주면 리다이렉션임. 리소스 서버가 리소스 오너의 웹 브라우저에 이 Location으로 이동시킴. Code=3에서 3이 임시 비밀번호인 authorization code임.
리소스 오너의 웹 브라우저는 리소스 오너가 인식하지도 못한 채로 그 주소로 이동함.
그러면 Client가 authorization code3이라는 정보를 알 수 있음.
Client가 resource server에 authorization code 3이라는 정보를 전달해야 함.
클라이언트는 리소스 서버에 요청한다.
Grant type은 현재 authorization code임. 이게 종류가 4개 있다.
Grant type, code, redirect uri, client id, client secret 값을 전송함.
중요한 것은 client secret값을 전송한다는 것이다. 절대 외부에 노출하면 안 되는데 리소스 서버에 이걸 보낸다! Authorization code와 함께
리소스 서버는 authorization code3을 인지하고 client id1, secret은 2인 client에 할당했음을 확인하고 클라이언트가 전송한 client id, secret, redirect uri 다 확인하고 일치하면 그때 다음 단계로 진행한다.
다음 단계가 access token 발급이다.
6. 액세스 토큰 발급
OAuth의 핵심인 access token의 값을 발급받는 과정을 알아보자.
리소스 서버가 클라이언트를 승인하는 과정을 알아봤다.
이제 access token을 발급한다. OAuth의 목적이 access token 발급임!
리소스 서버는 authorization code로 인증했으니까 그 값 이제 지워버림
리소스 서버는 access token을 발급함. 그리고 응답으로 access token 값을 보낸다.
클라이언트는 access token이 4임을 내부적으로 저장함.
이 access token은 클라이언트가 4라는 액세스 토큰으로 접근하면 리소스 서버가 user id 1인 사용자에 b, c 기능에 권한이 열려있음을 인지하고 정보를 허용함을 인지하고 동작함.
7. API 호출
API가 무엇인지, Access token을 이용해서 API를 호출하는 방법이 무엇인지 살펴본다.
지금까지 Access token을 발급받는 방법을 알아보았다.
Access token을 활용해 리소스 서버를 핸들링(조작)하는 방법을 알아보자.
그냥 막 할 수는 없고, 리소스 서버가 클라이언트에게 ~하면 우리를 쓸 수 있음을 알려준다. 이것이 API. Application Programming Interface이다.
우리 client가 리소스 서버를 호출하는 일종의 조작 장치가 API이다.
예를 들어서 구글 캘린더를 조작하고 싶으면 google calendar api 입력해서 문서를 보면 됨. API가 보인다. 구글 캘린더 리스트를 보여주는 API에 주소창에 쳐보면 로그인 Required가 뜸.
OAuth를 통해서 데이터를 받아올 수 있다. Access token을 어떻게 가져오는지는 각각의 application 수업을 통해서 살펴봐야 할 문제.
Access token을 우리가 구했다고 치자. 그다음에 어떻게 할 수 있을까?
Google api access token oauth 검색해보면 calling google apis가 있음. 2개의 방법. Access token을 쿼리 파라미터로 보내는 법. Authorization Bearer을 헤더로 보내는 방법. 두 개가 있는데 후자가 더 선호된다. ?access_token = ~
접속하면 목록이 매우 잘 보인다.
이것이 첫 번째 방법이다.
더 선호되는 방법은 헤더에 Authorization: Bearer를 전송하는 것.
Authorization헤더에 OAuth를 위해 고안된 Bearer 라는 인증방법 써주고
Curl 프로그램을 이용하면 손쉽게 볼 수 있다.
curl -H “Authorization: Bearer <토큰자리>” https:// .. ..
H뒤의 정보가 헤더라는 뜻.
curl이라는 프로그램을 써보면 된다.
웹페이지 데이터 가져올 수 있음.
이 방식이 더 안전하다.
8. refresh token
Access token은 수명이 있다. Access token의 수명이 다했을 때 새로운 access token을 발급받는 방법인 Refresh token을 알아보자.
Access token의 수명은 1~2시간에서, 길면 90일까지 수명이 있음.
Api에 접속해도 데이터를 안 줌. 그럼 access token을 다시 발급받아야 하는데 사용자한테 그 과정을 다시 거치게 하기는 너무 힘듦.
손쉽게 access token 다시 발급받는 방법이 refresh token임.
(A) 권한 획득 (B) Access Token과 Refresh Token을 함께 발급
모두 저장해놓고 있다가 API를 호출할 때는 Access Token을 보내고, (F) Invalid가 나오면 수명이 끝난거임. 그럼 (G) Refresh Token을 전달하면서 Access Token을 재발급받음.
Refresh token은 갱신될 수도 있고 안 될 수도 있음. Refresh 방법은 다 다르다.
아래는 구글의 예시. https://developers.google.com/identity/protocols/oauth2/web-server#httprest_7
댓글