[back-end]OAuth2.0/생활코딩 OAuth 2.0

진행하고 있는 프로젝트에서 OAuth2.0 을 이용한 구글 로그인을 구현하고자 한다.

OAuth2.0에 관한 개념을 명확히 정리한 후 라이브러리를 사용하면 더 수월하게 진행할 수 있을 것 같아서 

생활코딩 web2 OAuth2.0 강의를 수강한 후 정리해 보았다.

 

 

https://opentutorials.org/module/3668

WEB2 - OAuth 2.0

 

이 강의는 9개의 동영상, 47분 정도의 분량으로 짧게 핵심적인 내용을 담고 있다.

 

강의의 수업 대상은

"구글, 페이스북과 같은 서비스의 API에 사용자 대신에 접근하고 싶은 분들을 위한 수업입니다.

또 아래 그림과 같이 다른 서비스로 로그인 하기 기능을 구현하는데도 필수적으로 필요한 기능입니다. "

 

 

 

1. OAuth란?

내가 웹 서비스를 운영하고 있다고 하자.

이 웹 서비스 내에서 google, facebook의 기능(api)을 이용하고 싶을 수 있다.

예를 들면, 웹 서비스 내에서 google calender에 일정을 추가하거나, facebook에 글을 올리는 것이다.

사용자의 google calender와 facebook에 접근하기 위해서는 사용자의 id와 password가 필요하다.

그러나 사용자가 나의 무엇을 믿고 id와 password를 제공할 수 있을까?

또한, 내가 그 id와 password의 관리를 제대로 하지 못한다면 아주 큰 문제가 발생할 수 있다.

이러한 문제점은 oauth를 통해 해결할 수 있다.

id와 password를 사용자에게 직접 얻는 것이 아닌, 내가 google, facebook 등에 access token을 요청하면 

google, facebook에서 access token을 발급해주고, 그 access token을 이용하여 권한이 있는 범위 내에서 api를

사용할 수 있다.

 

 

 

2. 역할

 OAuth란? 에서 언급한 OAuth에 참여하는 주체는

-웹 서비스의 사용자(user)

-웹 서비스를 운영하는 나

-access token을 제공하는 google과 facebook

까지 총 3개이다.

이들은 oauth의 핵심으로, oauth 공식 문서에서 어떻게 명칭하는지 알아보자.

 

-resource server : google과 facebook 등 정보를 제공하는 주체(말 그대로 정보를 제공하기 때문에 resource server라고 한다.)

    *  공식 문서에서는 인증과 처리를 담당하는 부분을 authorization server라고 구분지어서 명명한다.

-resource owner : 웹 서비스의 사용자는 resource server가 제공하는 정보의 주인이기 때문에 resource owner라고 한다.

-client : 제공받은 정보를 이용하는 웹 서비스를 client라고 한다.

 

보통 애플리케이션 사용자를 client라고 하고, 웹 서비스를 제공하는 쪽을 server라고 하지만,

client와 server의 개념은 상대적이다. 

 

 

 

3. 등록

client가 resource server를 이용하기 위해서는 resource server의 승인을 받는 과정이 사전에 필요하다.

이 과정을 등록이라고 하고, 등록을 받는 과정은 서비스마다 다르다.

등록에 필요한 요소는 다음과 같다.

• client id(외부노출 가능,app(웹서비스)을 식별하는 식별자)
• client secret(비밀번호, 외부노출 절대x), 
• authorized redirect urls
  • resource server가 권한을 부여하는 과정에서 authorized code를 주는데 그때 그 코드값을 이 url로 전달하라고 하는 주소이다. resource server는 저 주소 말고 다른 주소에서 요청하면 무시한다.

 

 

내가 구현하고자 하는 google에서는 google cloud platform에서 등록을 할 수 있다.

https://cloud.google.com/

클라우드 컴퓨팅 서비스  |  Google Cloud

 

등록 과정은 등록을 이해하고 있다면 아주 간단해서 사진은 생략(절대 귀찮은거 아님 진짜 아님)

1. 프로젝트 생성
2. api및 서비스-사용자 인증 정보-oauth 클라이언트 id 생성
3. authorized redirect url도 등록한다(추후 수정할 수 있음)
4. 클라이언트 id와 secret이 생성된다! (secret은 공개하면 안됨 !!)

 

 

4. resource owner의 승인

등록 과정을 마치면 resource server와 client는 client id, client secret, redirect url을 알고있는 상태가 된다. 

resource server는 다양한 기능들을 가지고 있다. 만약 client가 resource server가 갖고 있는 기능 중 일부만 필요하다면,

모든 기능에 대해 인증을 받는 것이 아니라 필요한 기능에 한해 인증을 받는 것이 좋다.

 

resource owner(user)는 애플리케이션에 접근을 할 때 resource server를 사용해야 하는 경우가 있다. 

(ex) 페이스북에 글을 게시, 구글 캘린더에 날짜 기록 등

 

이때 resource server는 resource owner에게 이러한 창을 띄운다 :

• 페이스북, 트위터, 구글로 로그인하기 or 이러한 기능에 접근하기 위해서는 인증을 받아야 한다는 창

이 버튼이 담고있는 링크는 다음과 같다 : 

https://resource.server/

?client_id =1 (클라이언트 id)

&scope = B, C (resource server에 존재하는 기능 중 사용하고자 하는 기능의 범위를 지정)

&redirect_url=https://~~~ (redirect url)

    ** resource owner의 승인 과정은 다음과 같다

1. resource owner가 resource server의 저 주소로 접속을 하게되면 resource owner가 현재 로그인이 되어있는지 보고, 로그인 되어있지 않으면 로그인 하라고 요청한다.
2. 로그인을 하면 resource server는 전달받은 client 값(resource owner는 웹 서비스 내부에서 resource server에 접근하고자 한다. 이때의 clinet 값을 의미한다)이 자신이 갖고있는 client id값이 같은지 확인한다. 
3. 또 내가 가지고 있는 client id의 redirect url과 접속을 시도하려는 url이 같은지 확인하고, 같지 않다면 접속을 차단한다. 
4. 같다면 resource owner에게 scope에 해당하는 권한을 client에게 부여할 것인지 확인하는 메시지를 전송한다. 
5. 허용하면 resource server는 user id 1이 scope b, c에대한 작업을 허용하는것에 동의하였다는 정보를 서버에 저장한다.

 

 

 

 

5. resource server의 승인

resource server는 바로 access token을 발급하는 것이 아니라, 승인 과정을 하나 더 거친다. 

그 때 사용하는 임시 비밀번호를 authorization code라고 한다.

1. authorization code를 resource server가 owner에게 전달한다

//server가 owner에게 전달
location : https://client/callback/?code=3

code=3이 authorization code이다.

 

2. location 헤더값에 의해서 owner은 https://client/callback/?code=3 주소로 이동하게 된다.

3. client는 code를 갖게 된다. 

여기까지의 과정이 client가 server에게 code를 전달하여 token을 발급받기 전 과정까지이다. 

4. client가 아래와 같은 코드를 resource server에 전달한다. client secret과 authorization code를 함께 포함한 아주 중요한 과정이다!

//client가 resource server에 전송
https://resource.server.token?
grant_type=authorization_code&
code=3&
redirect_uri=https://client/callback&
client_id=1&
client_secret=2

resource server는 code를 보고 자신이 가지고 있는 코드 3번에 해당하는 정보와 일치하는지 확인한다.(authorization code, client id, secret, redirect url)

 

확인 후 다음 과정은 access token을 발급하는 것이다. 

 

 

 

6. access token 발급

resource server가 client를 승인하는 과정까지 마무리했다.

그 다음 단계는 access token을 발급하는 단계이다.

위에서 언급했다시피, oauth의 목적이 access token을 발급하는 것인 만큼 특별한(?) 단계이다!! 

1. client가 resource server에 authorization code를 전달하고, resource server가 client를 승인하는 과정까지 마무리 되었으므로 authorization code는 이미 인증을 받은 상태이기 때문에 resource server에서 지워준다. (또 인증을 받는 과정을 막기 위해서이다)
2. resource server는 accessToken을 발급한다.
3. 발급한 토큰을 클라이언트에게 응답해준다.
4. 클라이언트는 토큰을 내부적으로 db나 파일에 저장한다.

토큰의 활용 방법은 클라이언트가 토큰으로 접근을 하게 되면 server는 자신의 서버에 저장된 토큰을 보고

user id 1번의 사용자의 정보를(지정된 scope안의 범위 안에서) access token 4를 가진 client에게만 부여한다. 

 

 

 

7. api 호출

client는 aceess token을 활용하여 resource server를 다뤄야한다. client가 resource server를 사용하는 방법을 지정해 둔 방식이 있는데, 이를 api라고 한다(application programming interface). 즉, resource server를 호출하는 접점에 있는 조작장치를 api라고 한다. 

 

(ex) google calendar에 접근하고 싶다 

1. google calendar api 검색  https://developers.google.com/calendar/api

Google Calendar API  |  Google Developers

https://developers.google.com/calendar/api/v3/reference

API Reference  |  Google Calendar API  |  Google Developers

reference에 들어가 보면, 다양한 api들이 있다. 

만약, CalendarList를 get 하는 api를 사용하고 싶다면, 

https://www.googleapis.com/calendar/v3/users/me/calendarList/calendarId

링크를 통해 api를 호출할 수 있다. 현재는 api가 인증되지 않은 상태이다. 

oauth를 통해서, access token을 통해서 data를 가져올 수 있는데,

access token을 가져오는 방법은 각각의 애플리케이션에 따라 다르다. (추후의 java를 이용한 방법을 남겨볼 것이다.)

과정을 거쳐서 access token을 알아냈다고 하고, 그 후의 과정을 살펴볼 것이다. 

google api access token oauth를 검색해보자!

https://developers.google.com/identity/protocols/oauth2/web-server#callinganapi

웹 서버 애플리케이션용 OAuth 2.0 사용  |  Google ID 플랫폼  |  Google Developers

google api를 호출하는 방법에는 2가지가 있다. 

1. access token을 query parameter로 보내는 것

2. authorization : bearer를 header로 전송하는 것 (더 선호되고, 안전하다)

 

 

 

8. refresh token

또 새로운 토큰이 등장했다!

access token은 수명이 존재한다. 수명이 끝나면 토큰을 통해 api에 접속했을 때, api가 데이터를 주지 않는다.

이때 access token을 다시 발급받아야 하는데, 그때마다 위의 과정을 다시 거치는 것은 어렵다.

우리가 새로운 access token을 발급할 수 있게 해주는 것이 refresh token이다. 

 

검색 Oauth 2.0 rfc(인터넷과 관련된 기술들의 표준안)

rfc 6749번 : oauth에 대한 설명이 들어있는 표준문서이다. 

https://www.rfc-editor.org/rfc/rfc6749#section-1.4

RFC 6749: The OAuth 2.0 Authorization Framework

 

access token을 발급할 때 refresh token을 같이 발급하는 경우가 많다. (발급 후, 저장된다)

api를 호출할 때 access token을 사용하면서 resource server로부터 데이터를 가져온다. 

(f) invalid token error가 뜨면, access token의 수명이 끝났다는 것이다. 

이때 보관하고 있던 refresh token을 authorization server로 전달하여 access token을 다시 발급 받는다. 

(이때 refresh token은 그대로, access token만 재발급 받는 경우도 있고, 둘 다 재발급 받는 경우도 있다.)

refreshing 방법은 서비스마다 다르다. 공식 문서를 참고해야 한다. 

https://developers.google.com/identity/protocols/oauth2/web-server

웹 서버 애플리케이션용 OAuth 2.0 사용  |  Google ID 플랫폼  |  Google Developers

google의 경우에는 사진과 같은 방법으로 token refresing을 한다.