OAuth 2.0 기본원리

해당 게시물은 유튜브 생활코딩 채널의 WEB2-OAuth 강의를 듣고 작성한 포스트입니다.

 

WEB2 - OAuth 2.0 : 1.수업소개 - YouTube

 

강의 목표

OAuth 개념 이해하기

 

 

1. OAuth의 개념

OAuth를 사용하는 대표적인 예시로는 소셜로그인이 있다. 하지만 소셜로그인만이 전부가 아니다.

OAuth는 다른 서비스(보통은 신뢰할 수 있는 서비스. ex) google, facebook)와 원래 서비스를 연동한다. 
그러려면 사용자가 사용하는 해당 서비스 계정에 접근할 수 있도록 허가를 받아야 한다. 

가장 쉬운 방법은 사용자의 개인정보(아이디, 비밀번호) 등을 전달받아서 이를 SNS 계정에 접근할 때 이용하는 것이다.
그러나 사용자 입장에서는 자신의 개인정보를 처음 보는 서비스에게 맡기는 것은 불안하고, 보안상 문제가 있을 수 있다. 

OAuth는 이런 방법 말고, 토큰(Token)을 사용해서 안전하게 서로 다른 두 서비스가 상호작용할 수 있도록 해 준다. 

OAuth의 장점

1. 사용자의 실제 개인정보를 본래 사이트에서 사용하지 않는다. 즉 보안 면에서의 장점이 있다. 
2. 액세스 토큰으로 이용할 수 있는 SNS 서비스를 제한할 수 있다.

바로 위의 언급한 방법처럼 사용자의 실제 개인정보를 통으로 넘겨주게 되면, 해당 사이트에서 사용자 계정의 모든 권한을 갖는다는 점에서 보안 문제가 있다. 반면 액세스 토큰으로는 할 수 있는 일과 없는 일이 제한되어 있다. 마찬가지로 보안에서의 장점이 있다.

 

OAuth를 사용하는 방법

사용자의 개인정보를 사용해서, 사용하려는 다른 서비스의 사이트에서 로그인한다. 

사용자가 로그인하면 사용자의 실제 개인정보 대신 액세스 토큰을 발급하고, 본래 사이트에서 그 토큰으로 다른 서비스와 상호작용할 수 있다. 

 

2. 역할

 

Oauth에 등장하는 3개의 주체

resource owner : 사용자 
resource server : 기존 사이트에서 제어하고 싶은 자원을 갖고 있는 서버
client : 리소스 서버의 자원을 이용하려는 사이트

OAuth 공식 문서에서는 리소스 서버(resource server)를 resource server와 authentication server로 분리한다. 
resource server : 인증에 필요한 데이터를 갖고 있는 서버
authentication server : 인증 처리 및 작업을 하는 서버

*간단하게 보면 둘을 묶어서 그냥 리소스 서버로 보기도 한다. 

3. 등록

리소스 서버에 클라이언트를 등록하는 절차

클라이언트가 리소스 서버의 리소스를 사용하려면 사전에 미리 등록(register)을 해야 한다.

(Create app 이라는 과정으로도 나온다.)

등록에 필요한 정보

client id : 리소스 서버에서 개별 클라이언트에게 부여하는 id. 노출이 되어도 상관없다. 
client secret : 클라이언트가 리소스 서버에 자신을 인증할 때 사용하는 비밀번호. 노출되어서는 안 된다. 
authorized redirect urls : 리소스 서버는 이 url로 클라이언트에게 authorization code를 보낸다. 
만약 이 url이 아닌 다른 url에서 리다이렉트(redirect)요청이 들어온다면, 리소스 서버는 해당 요청에 대해서 응답을 보내지 않는다. 

실제로 등록하는 방법

사용하려는 리소스 서버 서비스의 developers 사이트에 가서, create app 또는 비슷한 메뉴를 찾아보자. 

 

ex)
Facebook : developers facebook 사이트에서 create app 메뉴 선택
Google : cloud platform 사이트에서 select/create project 메뉴 선택

4. Resource Owner의 승인

리소스 서버에 클라이언트가 사전 등록 작업을 마쳤다고 해 보자. 

클라이언트 서비스에서 리소스 오너의 정보로 리소스 서버의 서비스나 리소스를 이용하려면 추가적인 작업이 필요하다. 

우선 리소스 오너의 승인이 필요하다. 

ex. 리소스 유저가, 클라이언트 사이트가 나의 정보를 가지고 리소스 서버 사이트의 특정 기능을 사용하는 것을 승인

 

그 다음엔 리소스 서버의 승인도 필요할 것이다. 

ex. 리소스 서버 사이트에서 액세스 토큰과 같이 보낸 요청을 승인

과정

우선 등록이 완료된 이후, 클라이언트와 리소스 서버가 oauth에 필요한 어떤 정보를 갖고 있는지를 보자. 

클라이언트가 리소스 서버에 등록했을 때 사용한 client id, client secret, redirect URL의 정보를 둘 다 갖고 있다. 

 

만약 리소스 오너가 클라이언트 사이트를 이용하면서 소셜로그인 등의 '리소스 서버의 리소스를 필요로 하는 서비스'를 사용하려고 한다면, 흔한 소셜로그인 버튼 등이 나타날 것이다. 

리소스 오너가 그 버튼을 누르면(http 요청을 하면), 클라이언트 사이트는 응답과 함께 리다이렉트 URL을 리턴한다. 

리다이렉트 URL 예시

https://resource.server/?client_id=1&scope=B,C&redirect_url=https://client/callback

리다이렉트 URL은 리소스 서버와 클라이언트가 공통으로 가진 3개의 정보(client_id, client_secret, scope)중에서 client_secret을 제외한 2개의 정보를 쿼리 스트링으로 포함하고 있다. 

해당 url을 받은 리소스 오너는 받은 리다이렉트 url으로 리소스 서버에게 GET 요청을 보낸다.

(POST 처럼 따로 데이터를 담아서 보내지는 않는다.)

 

만약 해당 리소스 오너가 이미 리소스 서버에 로그인이 되어 있지 않은 경우(관련 토큰이 헤더에 없는 경우), 리소스 서버는 리소스 유저에게 리소스서버 로그인을 요청한다. 

참고로 로그인을 하지 않은 상태에서는 리소스 서버는 url 파라미터인 client_id, redirect_uri, scope는 아직 보지 않는다. 

여기서 리소스 오너가 로그인을 하면 다음 단계로 넘어간다. 

또는 이미 로그인이 되어 있었다면(관련 토큰을 헤더에 같이 넣어서 보냈다면), 리소스 서버는 이때 client_id와 redirect_uri를 확인한다. 

(만약 리소스 서버가 갖고 있는 client_id, redirect_uri 파라미터가 맞지 않는다면, 리소스 서버는 여기서 응답을 종료한다.)

만약 클라이언트가 보낸 값이 리소스 서버의 값과 일치한다면, 리소스 서버는 리소스 유저에게 클라이언트 사이트에서 scope에 해당하는 권한을 클라이언트에게 부여해도 되는지를 물어본다. 

(선택하는 작은 폼이 뜰 것이다.)

 

클라이언트가 해당 폼에서 allow를 누르면, 리소스 서버에는 리소스 유저의 id와 해당 리소스 유저가 허용한 scope 변수의 값이 저장된다. 

 

저장하는 이유는, 앞으로 해당 리소스 유저의 액세스 토큰으로 리소스 서버의 서비스나 리소스를 이용할 때, 해당 유저가 어떤 scope의 권한을 허용했는지를 알 수 있게 정보를 저장하는 것이다. 

5. Resource Server의 승인

 

리소스 유저가 scope에 대한 권한을 클라이언트에게 부여하는 걸 허용했다고 해도, 리소스 서버가 바로 액세스 토큰을 부여하지는 않는다. 

절차가 하나 더 있다.

리소스 유저가 scope에 대한 권한을 승인하고, 리소스 서버가 user_id와 scope를 저장한 이후, 리소스 서버는 리소스 유저에게 authorization_code를 리턴한다. 

authorization_code : 리소스 서버가 클라이언트를 인증하는 임시 비밀번호 역할을 한다. 

authorization_code는 아까 리소스 유저가 리소스 서버에게 보냈던 redirect_uri 파라미터 주소의 뒤에 쿼리 스트링을 추가한 형식으로 붙어서 보내진다. 

https://client/callback/?code=3

 

이 정보를 리소스 유저에게 응답으로 보낼 때, 리소스 서버는 이 정보를 헤더의 Location 파라미터에 넣어서 보낸다. 

그러면 리소스 유저의 브라우저는 location 파라미터에 있는 주소로 리다이렉트를 하게 된다. 

그러면 리소스 유저는 클라이언트에게 해당 url로 GET 요청을 보내는 셈이다. 

(redirect_uri의 도메인이 클라이언트의 도메인이기 때문이다)

그러면 클라이언트는 이제 authorization_code의 값도 알게 된다. 

이제 클라이언트는 리소스 유저를 통하지 않고, 리소스 서버에게 직접 요청을 보낼 수 있다. 

쿼리 스트링 파라미터로 url에 값을 넣은 형식이고, GET 방식으로 요청을 보낸다. 

 

url 예시

https://resource.server/token?grant_type=authorization_code&code=3&redirect_url=https://client/callback&client_id=1&client_secret=2

 

해당 url에는 grant_type, code, redirect_url, client_id, client_secret 정보가 포함되어 있다. 

이 중에는 2개의 비밀번호(auth_code, client_secret) 정보도 포함되어 있다.

+

강의에서 다루진 않았지만, 리소스 서버가 클라이언트를 인증하는 방법은 authorization code로 인증하는 방법 말고도 여러 개가 있다고 한다. 그래서 어떤 인증방법을 사용하는지에 대한 정보를 알려주기 위해서 

grant_type=authorization_code

라는 쿼리스트링이 붙는다. 

 

개인적인 Q

client_secret은 노출되면 안 되는 정보라고 했는데 저렇게 url 쿼리스트링으로 보내도 괜찮은 걸까?

 

리소스 정보는 자신의 DB에서 client_secret, auth_code 정보가 클라이언트가 보낸 정보와 일치하는지를 보고(ex. client_secret=2인 계정의 auth_code는 3이 맞는지), client_id, redirect_url 등의 나머지 정보가 맞는지도 확인한다. 

이제 다음 단계에서 액세스 토큰을 지급한다.

6. 액세스 토큰 발급

 

이제는 리소스 서버가 클라이언트에게 직접 액세스 토큰을 발급한다. 

해당 액세스 토큰은 리소스 서버와 클라이언트의 DB에 각각 저장되며, 각 리소스 유저마다 당연히 액세스 토큰의 값이 다르다. 

처음에 리소스 유저가 한번 '클라이언트에서 자신의 리소스 서버 계정에서 특정 기능들(scope)의 접근 권한을 얻는 것'에 동의하면, 그 이후로는 별도의 동의를 받지 않고 액세스 토큰을 사용할 수 있다. 

순서

1. 리소스 유저가 클라이언트 사이트에서 '소셜로그인' 등의 버튼을 클릭한다(클라이언트에게 요청을 보낸다).

2. 클라이언트는 리소스 유저에게 리다이렉트 응답을 보낸다(리소스 서버 로그인으로 리다이렉트).

3. 정보를 맞게 입력한 경우 기존에는 authorization_code를 보내서 추가 인증을 진행하였지만, 이제는 그러지 않는다. 

셀프 Q&A

Q. 리소스 유저가 리소스 서버의 로그인 정보를 맞게 입력한 경우 리소스 서버는 리소스 유저에게 어떤 응답을 리턴할까?

A(추측). 클라이언트로 리다이렉트 or (액세스 토큰 유효기간이 지난경우) 새 액세스 토큰 발급할 것 같다. 

 

 

7. API 호출

 

oauth를 이용하는 가장 중요한 목적

액세스 토큰 발급 이후 리소스 서버의 일부 기능을 사용하려면 리소스 서버의 API를 사용해야 한다. 

리소스 서버의 API는 리소스 서버에서 제공하는 여러 기능을 어떻게 사용할 것인지에 대한 표준 규격이라고 할 수 있다. 

각 리소스 서버는 API들을 어떤 형식으로, 어떤 파라미터 등을 넣어서 사용해야 하는지에 대한 정보를 공식문서로 제공하고 있다. 

ex. "구글 캘린더 API" 를 검색해서 나온 공식문서를 참고해서, 해당 형식으로 요청 보내면 데이터를 받을 수 있다. 

액세스 토큰 보내는 방법(2가지)

1. GET 요청으로 url 쿼리스트링에 access_token={access_token} 값 넣어서 보내기

상대적으로 간편하지만 보안 측면 때문에 덜 사용된다고 한다. 

 

2. GET 요청으로 보내되, 액세스 토큰은 헤더에 Authorization 값으로 넣고, Bearer 토큰 방식으로 보내기

보안 측면에서 더 좋다. 다만 일반적인 url 접근이 불가능하고, curl이나 postman같은 프로그램을 사용해야 한다. 

8. 리프레쉬 토큰 Refresh Token

 

액세스 토큰은 유효기간이 있다. 

리프레쉬 토큰은 처음 액세스 토큰이 발급될 때 액세스 토큰과 같이 발급되는데, 액세스 토큰이 만료되었을 때 새 액세스 토큰을 발급하는 데 사용된다. 

액세스 토큰을 발급받을 때는 보통 액세스 토큰, 리프레쉬 토큰, 만료기간의 값을 같이 리턴하는 것이 일반적이다. 

리프레쉬 토큰이 어떻게 발급되는지도 마찬가지로 사용하려는 각 리소스 서버의 공식문서를 참조하면 알 수 있다. 

ex. 구글의 경우 Google Identity Platform에서 관련 정보를 제공한다. 보통은 특정 url로 필요한 정보(client_id, grant_type, refresh_token 등)를 POST 방식으로 보내면 새 액세스 토큰을 발급하는 방식을 많이 쓴다. 

또한 리프레쉬 토큰의 경우, 새 액세스 토큰의 발급에 사용되면:

(1) 리프레쉬 토큰 값도 새로 발급해 주는 경우도 있고, 

(2) 리프레쉬 토큰 값은 그대로인 경우도 있다. 

9. 수업을 마치며

 

앞으로 공부해 볼 만한 주제

federated identity : 다른 서비스와의 연합을 통해 사용자를 식별하는 인증체계

RESTful API : 많은 형식의 API는 이 방식을 따르고 있다.