저번 포스팅에서는 o-auth를 이용해 Access Token을 발급 받기까지의 과정을 한번 훑어보았다. 이번에는 이 AccessToken을 활용해서 Resource Server를 핸들링 할 수 있는 방법을 한번 알아보자.

 

2024.03.19 - [학부연구] - [O-Auth] O-Auth란 무엇인가?

 

[O-Auth] O-Auth란 무엇인가?

O-auth는 한마디로 말해 인터넷 사용자가 특정 웹 리소스에 대한 접근 권한을 제3의 서비스에게 안전하게 위임할 수 있게 해주는 개방형 표준이다. 기본적으로 제 3의 웹사이트에서 다른 웹사이트

jghdg1234.tistory.com

이전 포스팅에서도 언급 되었지만, 각 리소스 서버는 각 리소스 서버만의 개별적인 인증 방식이 있다. 그렇다면 각각의 다른 인증 방식을 어떻게 찾아보고, 어떻게 핸들링 해야 할까? 바로 이러한 방식을 알려주는 도구를 API라고 한다(Application Programming Interface).

 

예시를 한번 들어보자. 

 

내가 구글 캘린더를 통해 리스트를 받아올 수 있는 리소스 서버(Google Calendar)를 핸들링 하고싶다고 해 보자. 그러면 인터넷에 google calendar api라고 쳐 보자.

 

구글 캘린더 API

그러면 위와 같은 화면이 보이는데, 위에 보이는 URI를 베이스로 해서, list를 GET 하고싶다고 해 보자.

https://www.googleapis.com/calendar/v3 + /users/me/calendarList 와 같이 주소창에 입력 해 보면, 저 주소가 바로 구글 캘린더의 리스트를 보여주는 api가 된다. 주소창에 입력 후 직접 들어가 보았다.

{
  "error": {
    "code": 401,
    "message": "Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
    "errors": [
      {
        "message": "Login Required.",
        "domain": "global",
        "reason": "required",
        "location": "Authorization",
        "locationType": "header"
      }
    ],
    "status": "UNAUTHENTICATED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "CREDENTIALS_MISSING",
        "domain": "googleapis.com",
        "metadata": {
          "service": "calendar-json.googleapis.com",
          "method": "calendar.v3.CalendarList.List"
        }
      }
    ]
  }
}

위처럼 에러 메시지가 출력되었다. <'Login Required'> 즉, 서비스를 사용하려면 인증을 거쳐 로그인부터 하라는 것이였다.

 

자 그럼 이제, Access Token을 받았다고 가정하고, 이 AccessToken을 통해 어떻게 인증 절차를 거치는지 한번 알아보자.

여러가지 방법이 있지만, 가장 많이 사용되는 인증 방식을 보자. 구글 API문서를 찾아보면,

더보기

curl examples

You can test these commands with the curl command-line application. Here's an example that uses the HTTP header option (preferred):

 
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

라고 명시되어있는데, curl다음의 -H는 '옵션'을 나타내고, 그 뒤에는 'Authorization'을 할것이라는 옵션을 추가 해준다.

 

위의 예시에서 보았듯이 아무것도 없이는 인증이 되지 않아 웹에 접속을 하면 오류 메시지를 출력한다. 하지만, 위의 방식에서 'access_token'으로 된 부분을 우리가 이미 발급받은 access_token으로 대체 해주고 그 뒷부분은 위에서 언급 되었던 캘린더를 가져오는 URI를 넣어주면, 우리는 성공적으로 서버에서 원하는 데이터를 가져올 수 있다.

 

방금 언급된 Bearer를 사용한 인증 방법은 표준화된 '안전한' 방식이기때문에 위의 방법을 쓰는것을 추천한다!

 

마지막으로, Refresh Token 에 대해 알아보자.

 

※ Refresh Token?

Access Token은 "수명" 이 존재한다. 이 수명이 만료되면, 더이상 리소스 서버는 이 Access Token을 채택하지 않는다. 그렇게 되면 이 Access Token이 만료 될 때마다 귀찮은 Access Token 발급 과정을 거쳐야 한다. 이런 경우에 우리가 손쉽게 Access Token을 받을 수 있는 방법을 Refresh Token 이라고 한다. 지금은 이렇게 간단히 뭐인지 정도만 살펴봤고, 나중에 직접 OAuth를 이용한 애플리케이션을 개발하는 포스팅을 해보겠다!

 

이렇게 O-Auth의 포스팅을 마무리하며 몇가지만 첨언하고 싶다. OAuth의 가장 매력적인 부분은 클라이언트 입장에서 제 3자인 리소스 서버(구글, 페이스북과 같은 안전한)를 통해서 리소스 오너의 신원을 인증 할 수 있다는 점이다.

+ Recent posts