생활코딩 OAuth2.0

OAuth 소개

1. 우리서비스를 이용하는 USER의 니즈

• 우리의 서비스를 이용하는 USER가 우리 서비스에서 일정을 관리하면 USER가 가입한 그들의 서비스에도 공유가 되는 기능이 필요함.

 

2. 구현 방법

• 우리의 서비스는 USER가 사용하고 있는 그들의 서비스에 접근할수 있도록 허가를 받고 그 서비스에 접근하여 기능을 수행.

• 우리의 서비스가 그들의 서비스에 접근하도록 허가를 받는 가장 간단한 방법

- USER가 그들의 서비스의 계정정보(ID,PW)를 우리 서비스에게 전달해서 그들의 서비스에게 허가 받음

하지만 우리의 서비스도, USER도, 그들의 서비스도 모두 불편....

 

3. OAuth가 하는일

• 우리의 서비스와 USER가 사용하고 있는 그들의 서비스의 안전한 상호작용을 가능하게 해줌

• USER의 계정 정보를 우리의 서비스에게 넘기는게 아니라 USER의 요청에 의해 그들의 서비스가 AccessToken이라는 일종의 비밀번호를 발급 (나의 서비스가 필요한 부분만 허용하는 비밀번호)

• 우리의 서비스가 OAuth를 통해 AccessToken을 획득한 후 AccessToken을 통해서 그들의 서비스에 접근 하여 데이터를 가져오고 수정하고 생성하고 삭제할 수 있음.

• 이걸 가능하게 해주는 기능이 OAuth

• USER의 계정 정보를 우리의 서비스에서 처음부터 보관하지 않고 회원을 식별할수 있는 기능을 구현할 수 있음

(USER가 가입한 그들의 계정을 통해 우리의 서비스에서 로그인 기능을 연동, federated identity라고함)

※ 이 기술의 기반 기술이 OAuth

 

 

OAuth의 3개의 주체

• USER = Resource Owner

• Mine(우리의 서비스) = Client

• Their(그들의 서비스) = Resource Server

 

 

OAuth의 등록 

※ 클라이언트가 리소스 서버를 이용하기 위해서는 리소스서버의 승인을 사전에 받아야 함

 

• 서비스마다 등록 방법이 다르지만 공통적으로 리소스서버에서 제공하는 항목과 입력해야하는 항목이 3개 있음

 - Client ID : 애플리케이션을 식별하는 식별자

 - Client Secret : 애플리케이션에 대한 비밀번호

 - Authorized Redirect URIs : 리소스서버가 권한을 부여하는 과정에서 authorize code를 전달하는데 그 코드를 전달 받는 곳의 주소, 다른 주소에서 요청하면 무시하게됨

※ 리소스서버에서 이 세가지를 찾아서 확인 및 입력.

 

 

OAuth Resource Owner의 승인

① Client에서 심어둔 리소스 서버 url로 링크

 - 회원 가입, 로그인 등 리소스 서버의 기능을 사용할 Client 페이지에 리소스 서버 링크추가

 - 리소스 서버 링크 예시 :  http://resource.server/?client_id=1&scope=B,C&redirect_uri=https://client/callback

② 리소스 서버에서 리소스 서버 계정 로그인 요청

③ 유저는 리소스 서버의 계정 로그인

 - 유저가 보낸 url 파라미터에서 client_id,redirect_uri를 리소스 서버가 가지고있는 Client ID, Redirect URL를 비교하여 일치하지 않으면 끝냄

④ Client서버가 신청한 필요기능(B,C) 확인 및 동의 요청

⑤ 동의 확인

⑥ 허용한 유저 정보 추가

 - 유저가 보낸 url 파라미터로 리소스 서버에 허용한 유저 정보를 추가함

 

 

OAuth Resource Server의 승인

① Resource 서버가 Authorization Code를 생성

② Redirect URL을 통해 authorization code 전송

 - ex) location : https://client/callback?code=3

 - 응답할때 header 값으로 location을 보내면 Resource Owner가 알아차리지 못하게 리다이렉션이 됨

③ Client에게 authorization code 전송

④ URI에 파라미터를 통해 Authorization code저장

⑤ authorization_code, Client ID, Client Secret, Redirect URL을 파라미터로 보내서 access token을 요청

 - ex) https://resource.server/token

         ?grant_type=authorization_code

         &code=3

         &redirect_uri=https://client/callback

         &client_id=1

         &client_secret=2

- Resource 서버는 URI의 파라미터를 통해 정상적인 요청인지 확인

 

 

OAuth 엑세스토큰 발급

① Authorization Code를 삭제

 - Resource 서버와 Client는 Authorizaiton Code를 삭제

 - 다시 인증을 반복하지 않기 위해

② Resource 서버가 AccessToken 발급

③ Client에게 access token을 응답

④ URL에 파라미터를 통해 AccessToken 저장

※ 클라이언트가 발급받은 access token으로 리소스 서버에 접근하게 되면 리소스 서버는 access token을 보고 해당되는 user에 대해 유효한 scope(기능)의 권한이 열려있는 것이라고 허용하게 됨

 

 

OAuth API 호출

• 리소스 서버를 핸들링 하기 위해서 리소스 서버가 작성해둔 사용 방법에 맞게 호출해야함

• 각 리소스 서버마다 API호출 방법이 문서로 나와있음

 

 

OAuth Refresh token

1. 리프레시 토큰이란

• 엑세스토큰은 수명이 있고 그 수명이 끝나면 API에 접속했을때 데이터를 주지 않음

• 그럴때마다 엑세스토큰을 다시 발급 받아야하는데 그것을 매번 사용자에게 시키기엔 불편함

• 손쉽게 우리가 엑세스토큰을 발급 받을 수 있게 하는 방법이 리프레시 토큰

 

※ RFC : 인터넷과 관련된 기술의 표준안

 

2. 리프레스 토큰의 동작 방식

※ 각 리소스 서버마다 Refresh token을 요청하여 Access Token을 재발급 받는 방법에 대한 API호출 방법이 문서로 나와있음