WEB2 - OAuth 2.0 (2)OAuth는 3자간 인증시스템

===

5.Resource Server의 승인

 

이전시간 :

사용자가 이런 작업을 하는걸 허용합니다 하고 승인버튼을 눌렀을 때,

그 정보가 RS에 가서,

RS는

user id : 1, scope: b, c

-> b, c에 대한 작업을 허용했다 Client id : 1 에게

=>Resource Owner의 허락을 획득했음

 

그럼 이제 RS가 승인해줘야 한다

 

RS의 승인은 바로 Access Token을 발급하지 않고, 절차가 하나 더 있다(삼자간의 일이니까 좀 복잡)

이때 사용하는 임시 비밀번호가 authorization code다

 

RS는 RO에게 authorization code를 전송한다

이런식으로

앞에 Location이 붙어있는데

응답할 때 헤더라고 하는 걸로 Location이라고 하는 값을 주면 redirection이라는건데

웹브라우저한테 http://client/callback?code=3이라는 주소로 이동하라고 명령하는 것

RS가 RO의 웹브라우저에게 하는 것

 

RO의 웹브라우저는 Location헤더값에 의해서 RO(사람)가 인식하지도 못하게 은밀하게 이 주소로 이동하게 됨 

그럼 저기 있는 ?code=3이라는 것에 의해 Client는 authorization code : 3이라는 값을 갖게 됨

 

이게 Client가 RS에게 authorization code : 3를 전송해서 access Token을 발급하기 전단계

 

이제 Client는 RO를 통하지 않고, RS에 직접 접속한다

이런주소로

grant_type=authorization_code : 우리가 a_c를 통해 3자간에 인증을 하고 있어(외에도 3가지 방법이 더 있다

code=3 : a_c값

redirect_uri

client_id

client_secret : a_c와 이 secret값 두개의 비밀정보를 결합해서 RS에게 전송하게 되는 것

 

 

그럼 이제 RS의 작업은

a_c

redirect_uri

client_id

client_secret

4개의 값이 완전히 일치하는지 확인, 모두 일치하면 다음 단계(액세스 토큰 발급)

 

===

6.액세스 토큰 발급(OAuth의 목적)

 

저번시간이 RS가 Client를 승인하는 과정

Client가 RO를 통해 authorization code를 받았다

그 다음 Client는 RS에 직접 정보를 전송(이때 client_secret이라는 절대 노출되면 안되는 정보를 직접 RS에 전송함 a_c와 함께)

 

RS는 a_c값을 통해 이미 인증을 했기 때문에 그 값을 지우고(그래야 다시 또 인증을 안한대)

이때 드디어 RS는 accessToken을 발급함

 

그리고 Client에 응답해줌

그럼 Client는 accessToken이 4라는걸 내부적으로 파일이나 DB에 저장함

 

그리고 AccessToken은 보장한다

RS는

Client가 4라고 하는 accessToken으로 접근하면

accessToken 4를 보고

아 이 4는 user id 1번에 해당되는 사용자의 유효한 기능인 b, c에 대해 권한이 열려있는 access key니까

accessToken 4를 가진 사람에게 [userid 1에 해당하는 사용자의 정보 + b + c]를 허용 해야겠다 하면서 동작

 

===

7.API 호출

 

발급받은 accessToken을 활용해서 RS를 핸들링

 

RS가 Client에게 우리를 쓰려면 이렇게이렇게 하면 우리를 사용할 수 있습니다 라고 알려주는 방식대로 해야한다

그 방식을 API라고 부른다

 

Application Programming Interface

 

Client는 RS를 호출해서 어떤일들을 할 것

RS를 호출하는 접점에 있는 일종의 조작장치를 API라고 함

 

이렇게 검색하면

참조가 나온다

여러 API들이 나옴

 

구글캘린더에 있는 List를 가져오고 싶어 그럼 CalendarList항목으로 가야겠지

저 하이라이트한 주소를 베이스로해서, list를 GET(▽이건메소드잖아)하고 싶다면 그 옆의 주소로 가면 된다고 써 있는 것

이렇게 주소를 적어주는 것이 바로 List를 보여주는 API다 (▽주소창에적는게 get이니까 get골라서 예시든건가)

 

접속하면

Login Required가 뜸

이 API는 인증이 필요한 API라는 뜻

이건 OAuth, 즉 accessToken을 통해서 데이터를 가져올 수 있다

 

accessToken을 어떻게 가져오는지는 각각의 애플리케이션(Java, Python..) 수업을 통해

 

accessToken을 구했다치면

그 다음엔

를 검색하니 이게 괜찮더라고요 하면서 누름

살펴보는데 시간이 많이걸렸어요

두 가지 방법이 있다

(1)access_token을 query parameter로 보내는 것

(2)Authorization: Bearer 를 header로 전송하는 것, 이게 더 선호되고 안전하다라고 돼 있음

밑에 examples도 있지

위 : calendarList에 접근하는 API

밑 : access_token

이러면 나온다! 근데 이 방법은 지원을 안하는 경우도 많다, 메뉴얼을 봐야해

 

좀 더 선호되는 방법 헤더로 하는걸 쓰자, 이게 표준화된 방식

 

이때 curl이라는 프로그램을 쓰면 좀 더 손쉽다

curl -H : 뒤에 따라오는 " "만큼의 정보는 헤더값

Authorization이라는 헤더값으로 Bearer라는 OAuth를 위해서 고안된 인증법을 앞에 놓고 뒤에 access_token을 적는 것, 그 뒤에 우리가 접속하려하는 api의 주소

 

이렇게 해놓고

terminal을 열고

curl이라는 프로그램은 웹페이지를 다운받는 것, naver는 안되네요(안되는게 있군)

여기다 저대로 치면 화면에 띄워준다

이렇게 하면 서버와 좀 더 안전하게 통신을 할 수 있다는 말

 

===

8.refresh token

 

accessToken은 수명이 있다

30분~90일까지

수명이 끝나면 API가 더이상 데이터를 주지 않는다

 

그럼 다시 발급받아야하는데 그때마다 사용자에게 그 과정을 다시 거치게하는건 힘들다(그걸 필수로 하게하는 시스템도 있다)

 

그런 경우에 손쉽게 새로 accessToken을 발급받을 수 있는 방법이 refresh token

rfc : 인터넷과 관련된 기술들의 표준안

(A) : Client가 Authorization Grant(권한 획득)

(B) : 앞에서 했던 복잡한 과정을 거쳐서 Authorization Server가 Access Token을 발급, Refresh Token까지 발급하는 경우도 많다

 

우리는 둘다 저장해놓고 있다가

 

(C) : Access Token으로 Resource Server의 Resource를 가져오는 것

(F) : Invalid Token Error : 유효하지 않은 토큰 에러, 토큰 수명 끝났다고

(G) : Client는 Reresh Token을 Authorization Server에게 전달하면서 Access Token을 다시 발급받는다

(H) :

경우에 따라서 refresh token도 계속 갱신되는 곳도 있고 access token만 갱신되는 곳도 있고

 

 

예제삼아서 생활코딩이 구글의 문서를 검색해봤음

여러분이 사용하는 RS마다 refreshing하는 방법이 달라서 구글도 메뉴얼을 제공, 우리가 Refreshing이라는 키워드를 모르면 할수가 없겠죠

POST 어쩌구 HTTP/1.1 : 어쩌구 라는 경로로

Host: 여기에

Content-Type: application/x-www-form-urlencoded 는 form에서 post방식으로 전송하란 말

 

저 분홍색 3개와 grant_type이라는걸 전송하면(OAuth의 스펙을 보면 표준화된 부분임, 다들 이렇게 동작할 것)

구글에서는 json format으로 return해주는데

저기에 새롭게 발급된 access_token과, 그게 얼마동안 유효한지 등의 정보를 담아서 보내준다

 

access token이 만료되면 어떻게 처리하면 되는가!

 

===

9.수업을 마치며

 

OAuth라는 인증시스템의 원리에 대해 알아봄

 

단체 채팅방이 없었을 때, 삼자간 약속잡기가 힘들었다

단톡방이 나오면서 약속의 대혁명이 시작됨

OAuth가 복잡한 것도 비슷하다

Client, RO, RS가 한자리에 모일 수 없는 상황에서, 어떻게하면 서로를 신뢰할 수 있을까 라고 하는 고민에서 출발한 기술

어려운게 당연하고 3번보면서 익숙해지시길 권합니다

 

누군가에게 설명을해보고

 

원리를 몰라도 대신해주는 라이브러리들이 많이 있다

근데 원리를 모르고 라이브러리를 사용하면 라이브러리 자체가 어렵게 느껴질 것

 

반면 원리를 알고보면 라이브러리가 얼마나 우리의 수고를 덜어주는지 공감할 수 있을 것

 

OAuth라고 하는 중요한 관문에 익숙해지시는 것은 어떨까요

 

 

OAuth의 가장 매력적인 부분은 Client입장에서 제 3자인 RS를 통해서 RO의 신원을 인증할 수 있다는 점

누군가가 구글이나 페북처럼 신뢰할 수 있는 RS를 통해서 우리에게 access token을 전달했다면

우리는 RS상에서 RO의 고유한 식별자를 획득할 수 있다

 

바로 이 식별자가 일반적인 서비스에서 ID와 pw가 하는 역할을 할 수 있게 되는 것

이렇게 다른 서비스와 연합을 통해 사용자를 식별하는 인증체계를 federated identity 라고 부름

이런 기능들이 저런 기술을 이용한 것

 

OAuth를 이용하는 궁극의 목적은 API를 제어하는 것

오늘날 많은 API가 Restful스타일로 설계되고 있다

또 API를 통해서 주고받는 데이터는 JSON, XML과 같은 데이터 포맷을 이용하는 경우가 많다

 

이런 키워드들에 해당하는 지식들을 접해보시는 것도 API를 잘 다루는데 매우 중요한 배경지식