Posts [Backend] OAuth
Post
Cancel

[Backend] OAuth

jeonyoungho Jul 13, 2021 2021-07-13T00:00:00+09:00
Oct 26, 2023 2023-10-26T20:05:34+09:00 12 min

OAuth란?

  • 특정 애플리케이션(sample.com)이 다른 애플리케이션(naver, google, facebook)의 정보에 접근할 수 있는 권한을 관리하는 오픈 스탠다드 프로토콜이다.
  • 위키백과에서는 아래와 같이 설명하고 있다.
    • 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹 사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는 접근 위임을 위한 개방형 표준이다.

OAuth가 생겨난 배경

  • OAuth가 나오기 이전에는 외부사이트와 인증 기반의 데이터를 연동할 때 인증 방식의 표준이 없었기 때문에 기본인증 방식인 ID/Password를 사용했다.
  • 즉, 다른 사이트의 사용자 데이터에 접근할 때 사용자 ID와 Password를 요청한 후에 해당 정보로 인증을 하는 구조였다.
  • 이는 사용자의 Password가 노출될 가능성이 크기에 보안상 매우 취약한 방식이였다.
  • 또한, 유저 정보를 얻은 third-party 애플리케이션은 해당 사이트의 모든 접근 권한을 갖게 되어 어느 서비스에도 접근할 수 있게 되는 문제를 가지고 있으며, 이 third-party 애플리케이션이 Password를 변경하기라도 한다면 사용자는 사이트 이용이 불가하게 되는 최악의 상황이 발생할 수도 있다.
  • 기본인증 방식인 ID/Password 방식이 아닐 경우엔 각자의 개발한 회사의 방법대로 사용자 인증을 하였는데 그러다보니 인증방식이 너무 제각각이 되어버렸다.
  • 이러한 문제를 해결하기 위해 좀 더 안전하면서도 사용자 인증과 권한 제어까지 할 수 있는 표준화된 인증방식을 마련하기 위해 OAuth가 생겨나게 되었다.

OAuth 1.0a 탄생

  • 2006년 11월 트위터는 OpenID를 탑재하는 작업을 하고 있었고, 같은 시기에 한 소셜 북마크 사이트에서도 OpenID를 사용한 인증 방법을 필요로 하고 있었다.

  • OpenId란?
    • OpenId 스펙만 준수한다면 누구나 OpenID로 인증 가능
    • 최초 한 번 OpenID 가입 후 인터넷을 이용하면서 OpenID를 지원하는 사이트를 만나는 경우 더 이상 회원 가입하지 않고 기존에 만들어 놓은 OpenId로 로그인할 수 있는 방법
  • 트위터 및 소셜 북마크 사이트의 4명의 웹 개발자가 만나 OpenID로 활용한 API로 인증 및 권한 부여를 동시에 제공하는 인증 프로토콜을 찾다가 결국 적당한 것이 없다고 결론을 내리고 만든 것이 OAuth1.0이다.
  • 2007년 10월에 OAuth core1.0이 비공식 발표 되었지만, 나중에 세션 고정 공격 보안 결함이 발견되어서 이를 보완한 OAuth 1.0a가 2009년 6월에 발표되었고, 이후 2010년 4월에 “The OAuth 1.0 Protocol”이라는 이름으로 RFC 5849 문서 번호를 부여 받게 되었다.
  • OAuth1.0a는 API를 인증함에 있어 third-party 애플리케이션에게 유저 Password를 노출하지 않고 인증을 한다는 점과 인증과 권한 부여를 동시에 할 수 있다는 점에서 기존 인증방식의 부족한점을 보완하기에 충분한 듯 보였다.
  • 하지만 다음과 같은 문제점이 남아있었다.
    • 모바일 애플리케이션에서 지원하지 않음(웹 애플리케이션 지원)
    • signature(전자 서명)을 개발하고 관리하는데의 번거로움
    • 기능은 단순화하고 규모는 확장하고 싶은데 복잡하다.

OAuth 2.0 탄생

  • 2012년 10월에 드디어 위와 같은 문제점을 보완하여 OAuth2.0이 발표되었다.
  • OAuth 1.0과 OAuth 2.0의 크게 달라진 점은 아래와 같다.
    • 전자 서명이 아닌 HTTPS 사용
    • Access Token의 만료 기간이 생김
    • 더 많은 인증 방법(Grant types) 지원 -> Implitct Grant를 사용해 모바일에서도 지원 가능
  • OAuth 1.0a에서는 HTTPS가 필수가 아니었기 때문에 API를 호출할 때 Signature(전자 서명)를 생성해서 호출해야했지만 OAuth 2.0는 암호화를 HTTPS에 맡김으로써 개발자의 수고를 덜어주었다.
  • 또한, 다양한 인증 방식을 통해 웹/모바일 등 다양한 시나리오에 대해 적용할 수 있게 되었다.

OAuth 2.0 구성

  • Resource Owner
    • 사용자, 나
    • 이미 google, facebook, naver 등에 가입된 유저로 Resource Server의 Resource Owner
  • Resource Server
    • 자원을 호스팅하는 서버
    • google, facebook, naver 등 OAuth 제공자
  • Client
    • 리소스 서버에서 제공하는 자원을 사용하는 애플리케이션
    • Naver band, Notion 등등
  • Authorization Server
    • 사용자 동의를 받아서 권한을 부여 및 관리하는 서버

OAuth 2.0 동작방식

1 출처: https://velog.io/@piecemaker/OAuth2-%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

위 이미지 출처 블로그를 통해 더욱 자세하게 동작방식을 확인할 수 있지만, 요약하면 다음과 같다.

1) 먼저 내 웹 사이트의 URL, 리다이렉트URL을 인증 대행 서버에 등록 후 클라이언트ID(client id) 와 비밀번호(secret key)를 발급받는다.

2) 사용자가 내 웹 사이트에서 구글 로그인 버튼을 클릭하면 내 웹 사이트에서 구글 인증 서버 로그인 페이지로 리다이렉트 시켜준다. 이때 구글 인증 서버 로그인 페이지URL의 파라미터로 클라이언트ID를 넘겨줌으로써 구글 인증 서버에 내 웹 사이트에서 OAuth인증 요청을 한 것을 식별할 수 있다.

3) 사용자가 로그인을 수행 후 접근 권한에 동의하면 구글 인증 서버에서 authorize_code를 발급하여 1번에서 등록한 리다이렉트URL로 보내준다.

4) 내 웹 사이트는 전달 받은 authorize_code와 리다이렉트URL, 클라이언트 ID 및 비밀번호를 HTTP Body에 담아 전송하여 액세스 토큰을 요청한다.

5) 구글 인증 서버는 액세스 토큰을 발급하여 내 웹 사이트로 제공한다.

6) 내 웹 사이트는 액세스 토큰을 바탕으로 유저의 정보를 요청하여 받아온 후 사용자를 인증한다.(단순하게 액세스 토큰을 사용하여 유저 정보를 받아오기만 할 뿐, 유저정보는 내 웹 사이트에서 관리한다.)

7) 이러한 액세스 토큰은 사용자의 브라우저 캐시에 저장되거나 웹 서비스 세션에 저장함으로써, 액세스 토큰이 만료되지 않는 한 브라우저를 종료했다 다시 접속해도 자동으로 이전 로그인 정보로 로그인 되도록 할 수도 잇다.

Access Token과 Refresh Token을 사용한 인증 과정

OpenID와 OAuth의 차이점

OpenID도 인증을 위한 표준 프로토콜이고 HTTP를 사용한다는 점에서 OAuth와 같다. 하지만 둘은 목적이 다르다. OpenID의 주요 목적은 인증(Authentication)이지만, OAuth의 주요목적은 허가(Authorization)이다. OpenID는 OpenID Provider에서 사용자의 인증과정을 처리한다. OpenID를 사용하는 여러 서비스는 OpenID Provider에게 인증을 위임하는 것이다. 물론 OAuth에서도 인증 과정이 있다. 가령, Facebook의 OAuth를 이용한다면 Facebook의 사용자인지 인증하는 절차를 Facebook(Service Provider)이 처리한다. 하지만 OAuth의 근본 목적은 해당 사용자의 담벼락에 글을 쓸 수 있는 API를 호출할 수 있는 권한이나, 친구 목록을 가져오는 API를 호출할 수 있는 권한이 있는 사용자인지 확인하는 것이다. OAuth를 사용자 인증을 위한 방법으로 쓸 수 있지만, OpenID와 OAuth는 근본 목적이 다르다.

출처

Backend, Security
oauth google naver kakao facebook
This post is licensed under CC BY 4.0 by the author.
Recent Update
Contents

[Backend] JWT와 OAuth의 관계

[Backend] 서버 인증 방식의 종류