Hannah Seong

3 minute read

1. OAuth란?

OAuth 2.0(Open Authorization 2.0, OAuth2)은 2006년 Twitter와 Google이 정의한 개방형 Authorization 표준이며, API 허가를 목적으로 JSON(Javascript Object Notation) 형식으로 개발되었습니다. 제 3의 프로그램에게, 리소스 서버가 리소스 소유자를 대신해서 자원을 제공하기 위한 접근 권한을 위임하는 방식을 제공하는 표준화된 기술입니다.

예를 들어서, 요즘 간단한 웹애플리케이션들은 대부분 각종 소셜 로그인을 제공하고 있습니다. 우리는 이를 이용하여 간단하게 회원가입/로그인(로그인 기능은 정확히 말하자면 Auth의 상단 계층인 OpenID Connect를 활용합니다)할 수 있고, API를 호출하여 구글, 카카오, 네이버 등(편의상 이후로는 카카오로 예를 들겠습니다.)에 저장된 나의 정보를 사용, 가공할 수도 있습니다.

이는 카카오와 같은 리소스서버가, 권한이 위임된 애플리케이션에 나의 정보를 나 대신 제공하고 있기 때문입니다. 어떻게 작동하는 것일까요?

1-1 OAuth의 배경

  1. 웹애플리케이션은 회원정보가 필요합니다. 회원가입을 위한 이메일 or 닉네임 정도일 수도 있고, 본격적인 애플리케이션 사용을 위해 사진, 캘린더 정보, 현재 위치 등 더 다양한 정보를 요구할 수도 있습니다.
  2. 사용자는 서비스 이용을 위해 정보를 모두 다 입력하고 인증하는 것이 번거롭습니다. 또한 자신의 소중한 정보를 신뢰할 수 없는 애플리케이션에 입력한다는 것은 보안적으로 위험할 수 있습니다.
  3. 카카오 서버는 이 모든 정보를 가지고 있고, 사용자가 로그인으로 인증만 한다면, 웹 애플리케이션에 정보를 제공할 수 있습니다.
  4. 그럼 사용자는 이제 웹 애플리케이션을 통해 카카오에 로그인을 하면 되는데, 어떻게 하면 좋을까요?
  5. 제일 간단하게 생각해볼 수 있는 방식은, 웹에 카카오 id/password를 제공하는 것일 것입니다. 이게 내 id/password니까, 이걸로 카카오에 들어가서 정보 가져와~ 하는 방식이죠. 그리고 여기에는 다음과 같은 문제들이 있습니다.
    • 사용자가 뭘 믿고 애플리케이션에 id/password를 제공하는가?
    • id/password를 제공하면, 애플리케이션은 카카오에 등록된 사용자의 모든 정보에 접근 가능해지게 됩니다.
    • 카카오 id/password를 바꾼다면, 애플리케이션은 기존에 제공받은 id/password로 카카오를 더이상 사용하지 못하게 됩니다.
  6. 따라서 안전한 방식으로 정보의 접근 권한을 위임하기 위해, 토큰을 사용하는 방식을 채택하게 되었습니다.
    • 이 토큰을 통해, 웹 애플리케이션은 꼭 필요한 사용자의 부분적인 정보에 대한 접근 권한만을 위임받습니다. 캘린더면 캘린더, 위치면 위치, 이런 방식으로요.
    • id/password가 아니라는 장점이 있습니다.

1-2 OAuth 관련 주요 용어

  • Resource Owner : 자원 소유자. 클라이언트를 인증(Authorize)하는 역할을 수행하며, 인증이 완료되면 접근 권한을 클라이언트에게 부여합니다. 웹 애플리케이션을 사용하는 사용자를 의미합니다.
  • Resource Server : 자원 소유자의 보호된 자원을 호스팅하는 서버를 말합니다. 예를 들면 카카오, 구글 등입니다. Access Token을 통한 자원에 대한 요청에 응답합니다.
  • Client : 보호된 자원에 대한 접근 요청을 만드는 애플리케이션입니다. 예를들어 일정관리 앱이 있고, 이 일정관리 앱이 구글이라는 리소스 서버에서 캘린더 정보를 가져온다고 가정할 때, 이 일정관리 앱이 바로 클라이언트입니다.
  • Authorization Server : 리소스 오너가 성공적으로 인증을 수행하고, 클라이언트가 접근권한을 부여받을 때 엑세스 토큰을 발행하는 서버입니다.
  • Access Token : 리소스 서버에게서 자원을 획득할 때 사용하는 토큰으로, 만료기한이 상대적으로 짧습니다.
  • Refresh Token : Access Token이 만료되었을 때, 이를 갱신하기 위한 용도로 사용하는 토큰입니다.

2. OAuth의 다양한 flows

OAuth는 다양한 권한 위임 방식(flow)을 가지고 있습니다. 다음 포스팅에서 Authorization Code Flow만 정리하려고 하는데요, 이것이 가장 많이 쓰이는 방식이기 때문입니다. 일반적으로 OAuth2.0하면, 이 방식을 가리키는 것으로 생각하면 될 것 같습니다. 따라서 여기서는 어떤 플로우들이 있는지 간단하게만 짚고 넘어가겠습니다.

2-1. Authorization Code Flow

authorization code를 token으로 교환하는 방식으로, 다음과 같은 순서로 이루어집니다.

  1. 유저가 애플리케이션의 로그인 링크를 클릭합니다.
  2. authorization server로 리다이렉트되고, 유저가 로그인을 실행합니다.
  3. 일반적으로, 유저는 어떠한 정보를 허용할 것인지 선택하고 동의합니다. (우리가 카카오 로그인을 할 때 허용정보를 선택하는 것처럼)
  4. 유저는 애플리케이션으로 리다이렉트되며, 일회성의 authorization code를 제공받습니다.
  5. 애플리케이션은 authorization code, client Id, client secret을 authorization server로 포워딩합니다.
  6. authorization server는 Id token, access token, refresh token(선택사항)을 생성하여 제공합니다.
  7. 애플리케이션은 이제 access token을 이용하여 유저의 정보와 함께 target API에 접근할 수 있습니다.

2-2. Client Credentials Flow

클라이언트(애플리케이션)의 자격을 증명하는 것만으로 access token을 획득할 수 있는 방식입니다. 클라이언트가 리소스 서버에게 신뢰할 수 있는(회사 내부 서비스라든가) 경우에 사용할 수 있을 것 같습니다.

2-3. Resource Owner Password Flow

리소스 오너(유저)는 애플리케이션에 credentials(id/password)를 입력하고, 그것이 authorization server로 전달되어 access token이 전달됩니다.

2-4. Implicit Flow with Form Post

authorization code없이 바로 access token이 발급되는 방식입니다.

2-5. Authorization Code Flow with PKCE

Proof Key for Code Exchange(PKCE) 방식입니다. authorization server가 proof key를 사용하여 code를 검증하는 로직이 추가됩니다.

3. 더 공부해볼 것

  • OpenId Connect

참고

auth0

광고

Comments

You May Also Enjoy