OAuth2 개념 이해하기

OAuth2 개념 이해하기

OAuth란?

---

Mine

내가 운영하고 있는 서비스로 www.book.com과 같은 것

User

Mine 서비스를 사용하는 일반 사용자

Their

User가 사용하는 제 3의 서비스로 facebook, google, kakao등

위의 세 가지 용어를 풀어보면, Mine은 고객인 User의 구글 캘린더에 일정을 등록하는 기능을 만들어야 한다고 가정해보자.

이 경우 Mine은 User의 구글 아이디와 비밀번호를 알고 있어야 하고, 문제없이 관리해야 한다.

그리고 이 정보를 갖고 구글에 접근하여 캘린더에 등록해야 한다.

이 경우 문제가 발생하는데 크게 세 가지로 나눌 수 있다.

• Mine은 User의 다른 서비스 계정을 관리하는 것 자체가 부담이다.
• User는 누군지도 모르는 서비스에 아이디와 비밀번호를 제공하는 것이 위험하다.
• Their는 자신의 사용자들 아이디, 비밀번호를 다른 서비스에 유출하는 것 자체가 위험하다.

이런 위험을 개선하기 위한 방법이 OAuth이다

직접 Their의 아이디, 비밀번호를 관리하지 않고, User의 요청에 의해 Their로 부터

accessToken을 발급 받는다. accessToken을 이용해서 Their에 접근할 수 있다.

OAuth의 용어 3인방

---

Resource Server(Their)

실제로 리소스를 제공하는 서버를 의미한다.

보통 Oauth하면 많이 쓰이는 Resource Server는 facebook, google, kakao등이 있다.

Resource Owner(User)

Resource Server에 가입이 되어있는 사용자를 의미한다.

만약 내가 구글에 가입이 되어서 구글의 로그인 기능을 사용하거나, 구글의 캘린더 기능을 사용한다고 할 때

Resource Server에서는 아무에게나 정보를 제공하는 것이 아닌 Resource Owner가 맞는지 확인하고,

그에 맞는 Resource를 제공하게 된다.

Client(Mine)

우리가 직접 운영하는 서버를 의미한다. 만약 도서 플랫폼을 운영한다면, www.book.com이 된다.

Resource Sever에 접근하는 서버를 의미하고, 이 서버는 Resource Owner가 이용하는 플랫폼이고,

Client는 로그인을 기능을 제공 받기 위해 Resource Owner의 권한을 이용해 Resource Server에게

요청하여 Resource Server를 이용하게 된다.

즉, 여기서 기준이 되는 것은 Client 기준으로 용어가 정리된다.

Register(등록)란?

---

Client가 Their에게 승인을 받는 것을 의미한다. 이 방법은 서비스마다 다르기 때문에 문서를 참고하면 된다.

만약, 구글이라면 구글 플랫폼에 들어가서 프로젝트를 만들어서 아래 세 가지를 설정해서 정보를 사용하는 것

일반적으로 필요한 것들

• Client ID: 1
  • 노출되어도 상과없음
• Client Secret: 2
  • 절대 노출되면 안됨
• Authorized redirect URIs: https://client.com/callback
  • 등록을 하면 Their는 Authorization code를 주는데 그것을 받을 redirect uri를 의미한다.
    여기에 query string으로 온다.

Resource Owner의 승인 과정

---

1. 등록 과정을 거치면 Client, Resource Server는 기본 정보인 Client Id, Client Secret, redirectURL
   을 알고 있다.

   2 . Client는 ResourceOwner에게 아래와 같은 url을 제공하면 된다.
   https://resource.server/?client_id=1&scope=B,C&redirec_url=https://client/callback
   참고로 scope은 프로필, 성별 등과 같은 제공할 정보를 정하는 것이다.

2. 이제 Resource Owner가 Client가 제공한 2번의 url을 접속을 하면, 로그인이 되어 있는지
   체크를 하고, 되어 있지 않다면 로그인 창을 주고 로그인을 요청한다.

3. Resource Owner는 로그인을 하면, Resource Server는 요청한 url의 client_id가 존재하는지
   확인하고, 같다면 redirect_url이 같은지 확인한다. 이게 맞으면 다음으로 넘어간다.

4. 이후 url에 있던 scope을 어떤 Client가 요청하고 있다고 보여주고,
   이를 Resource Owner는 승인하면 된다.

5. 승인이 되면, Resource Server는 승인한 Resource Owner(user_id로 체크)가 어떤 scope을
   제공했다는 정보까지 갖게 된다. 그럼 Resource Server는 최종적으로 아래의 정보를을 갖게 된다.

   • Client_id
   • Client_secret
   • redirect_url
   • user_id
   • scope

Resource Server의 승인 과정

---

여기서 핵심은 authorization code이다.

1. Resource Server는 Resource Owner의 승인이 끝났으면, redirect_url에
   authorization code를 보낸다. https://client/callback?code=3

2. Resource Owner는 redirect에 의해 Client에게 code를 전달하게 된다.

3. 그럼 Cliet는 authorization code를 알게 된다.

4. Client는 Resource Server로 다시 요청을 하게 되는데 이 때 요청하기 위해 필요한 데이터는
   아래와 같다. 이 정보들은 Resource Server도 모두 알고 있기 때문에 이 모든 것이
   일치하는지 확인하게 된다.

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

Access Token 발급 과정

---

Resource Server와 Client는 승인 과정이 끝났기 때문에 authorization code를 지우게 된다.

이미 인증이 끝났기 때문이다.

1. 이제 Resource Server는 accessToken을 생성한다.
2. Client에게 Resource Server가 accessToken을 전송한다.
   이제 Client, Resource Server는 accessToken을 알고 있다.
   Client는 accessToken을 발급 받은 것이다.
3. Client가 accessToken으로 Resource Server에 접근하게 되면,
   Resource Server는 accessToken을 확인해서 그와 맞는 정보를 보내주게 된다.

AccessToken으로 API 사용 방법

---

사용하는 방법을 전부 설명하지는 않고, 방법 2가지만 간단하게 알아보자.

상세한 내용은 문서를 찾아보면 쉽게 알 수 있다.

google api 문서를 보면, queyr string과 Authorization: Bearer 바아법이 있다고 한다.

Authorization을 권장한다고 한다.

Refresh Token

---

보안상으로 access token을 탈취 당하면, 방어할 방법이 없기 때문에 refresh token을 제공한다.

그래서 보통 access token은 시간을 짧게 유지하고, refresh token으로 access token을 재발급

받는 용도로 사용된다.

참고 자료

---

https://www.inflearn.com/course/web2-oauth2/unit/36282?tab=curriculum