OAuth2.0를 알아보자


요즘 로그인 및 회원가입 구현 시 필수라는 Oauth2.0에 대해서 개념을 자세하게 톺아보고자 한다.

OAuth란?

풀네임으로는 Open Authorization으로 부르며, 웹 및 애플리케이션 인증 및 권한을 부여하는 개방형 표준 프로토콜이다.

설명에 앞서, 일단 유명 포털의 개발 문서에서 정의된 내용을 한 번 가져와봤다.

이 프로토콜에서는 third-party 애플리케이션이 사용자의 리소스에 접근하기 위한 절차를 정의하고 서비스 제공자의 API를 사용할 수 있는 권한을 부여합니다.
대표적으로 네이버 로그인, 구글 로그인과 같은 소셜 미디어 간편 로그인이 있습니다.
OAuth2.0을 사용해 third-party 애플리케이션이 사용자의 소셜미디어 프로필 정보에 접근할 수 있도록 합니다.
B2B PRISM Live Studio 역시 OAuth2.0을 사용하여 권한을 관리하기 때문에 OAuth2.0의 기본 개념을 안내하고, 권한 부여 방법을 설명합니다.

출처: NCP 개발 문서

어느 정도 개발자 짬이 찬 사람이라면 바로 이해할 수 있겠지만, 개발에 입문한지 별로 안됐거나 개발 문서 읽는게 아직 익숙치 않은 사람들은 뭔 소린가 싶을 것이다.

쉽게 설명하자면, OAuth는 다른 사이트, 앱에서 소셜 회원가입/로그인 (또는 간편 회원가입/로그인이라고 함)을 할 때 사용되는 것이라고 보면 된다.
가령 어떤 사이트에 로그인을 할 때 Google로 로그인하기, Naver로 로그인하기가 보인다면 이 때 OAuth를 사용한다는 의미이다.



OAuth “2.0”

인터넷에 검색해보면 대부분 2.0이라는 버전을 찾을 수 있는데, 현재 대중적으로 사용하는 버전이 2.0이기 때문이다.

즉 이전 버전(=1.0)이 있었으며, 이전 버전에서 보완할 점이 생겨서 2.0이 나왔다고 생각하면 된다.

이전에 사용한 것에서 어떤 문제가 있었는지, 그리고 최근에는 왜 2.0을 사용하는지 알아보자.

(1) 기존 인증 방식: Basic Authentication

어쨌든간에 개발자 입장에서 로그인 한 유저에게 프로그램 접근 권한을 주기 위해서는 인증이 된 유저라고 표시를 해야하긴 한다.

따라서 기존에는 Basic Authentication (흔히 Auth라고 부름)에 따라, 애플리케이션에 사용자의 아이디 & 비밀번호를 직접 제공해 접근 권한을 줬다.

하지만 다음의 문제가 항상 거론되었고, 이 때문에 OAuth 1.0이 생겨났다.

  • 보안 취약성: 클라이언트가 사용자의 자격 증명을 저장하거나 전송하는 과정에서 유출 위험
  • 권한 관리 불가: 특정 자원에 대한 제한적인 권한 부여가 불가능. (모든 권한이 열림)
  • 복잡성 증가: 사용자 비밀번호가 변경되면, 이를 사용하는 모든 서비스에서 수정해야 함

한줄 요약하면 해킹 당하면 모든 정보가 털려서 문제라는 의미이다.

(2) OAuth 1.0의 등장 및 제한점

개발 배경

소프트웨어는 나날이 발전하고 있고, 이 때문에 사람들은 보안에 대해 깊게 생각하게 되었다.
그래서 나온 개념이 바로 OAuth 1.0이다.

개발자 입장에서는 보안을 되게 민감하게 받아들여야 하고, 하지만 관리가 매우 빡세다보니 구글이나 네이버같이 (주로) 대기업에서 이미 구현해둔 인증 로직을 가져와서 사용하는 것이다.
대기업에서 구현한 인증 로직은 아무래도 중소규모 기업들에 비해 보안 관리가 빡셀 것이며, 만약에 정보가 털렸다고 해도 책임이 대기업에게 있지 우리같은 소시민에게는 없기 때문이다.
폭탄 돌리기
물론 구현 잘못해서 정보 노출되게 코딩하면 우리 잘못이긴 하다

물론 그 외에도, 이런 인증 로직 하나 구현하는게 좀 빡센 편이라 이미 구현한거 가져와서 개발 시간을 아끼는겸 사용하기도 한다.

Auth와 다른 점

OAuth 1.0에서는 남이 구현한 사용자 인증 로직을 가져오는 것이기 때문에, 내가 해당 인증 로직을 가져와도 되는가를 증명할 수단이 필요하다. 이것이 바로 HMAC-SHA1 (서명 기반 인증)이다.
이 로직을 이용하면 기존에 구현된 인증 로직을 바탕으로, 아이디 및 비밀번호를 넣으면 접근 권한을 받아올 수 있다.

한계점
  • 복잡한 프로세스: 요청마다 일일이 서명 생성 및 검증이 필요 -> 구현 및 디버깅이 어려우며, 개발자에게 너무 많은 학습을 요구함
  • 확장성 부족: 특정 인증/권한 시나리오에 맞춰 설계되어 다양한 클라이언트 유형(SPA, 모바일 애플리케이션 등)에 적용하기 어려움
  • TSL 의존성 부족: 사실 상 원인
    • 서명으로 보안은 강화했으나, TLS를 필수로 요구하지 않아 Man-in-the-Middle에 매우 취약적
    • (참고) Man-in-the-Middle(중간자 공격): 두 당사자 간의 통신을 가로채서 조작 및 엿듣는 사이버 공격 방식

      (위치 선정)
      공격자는 클라이언트(사용자)가 사용하고 있는 wifi에 접속함
      그리고 클라이언트와 서버 사이의 통신 경로에 잠복

      (통신 가로채기)
      이 때 클라이언트가 서버에게 요청을 보냄
      서버에 도달하기 전에 해당 요청을 공격자가 가로챔
      클라이언트가 요청한 정보를 수정하거나 읽고 서버에 전달

      (응답 가로채기)
      마찬가지로, 서버에서 클라이언트에게 보낸 응답도 공격자가 가로챔
      서버가 보낸 응답 내용을 수정하거나 읽고 클라이언트에게 전달

(3) OAuth 2.0의 등장

이렇게 OAuth 1.0의 한계를 극복하고자 나온 것이 바로 OAuth 2.0이다.

  • 프로세스 간소화: 서명 대신 Access Token을 사용해서 요청을 단순화
  • 확장성 및 표준화
    • 확장 가능한 구조로, 추가적인 인증 메커니즘(JWT, OpenID Connect 등)과 쉽게 통합 가능
    • 다양한 플랫폼과 서비스(Google, Facebook, GitHub 등)에서 표준으로 채택
    • 다양한 클라이언트 유형 지원
      • 다양한 Grant Type 제공:
        • Authorization Code Grant: 서버 사이드 애플리케이션.
        • Implicit Grant: 브라우저 기반 애플리케이션.
        • Client Credentials Grant: 서버 간 통신.
        • Resource Owner Password Grant: 신뢰할 수 있는 클라이언트.
      • 각 시나리오에 맞는 유연한 인증 방식 제공.
  • TSL 필수 사용: 데이터 전송 중에 보안을 보장하여 데이터의 무결성 입증 가능

기능이 개선이 되었지만, 이것이 그렇다고 ✨만능✨인 것은 아니다.
현재 크게 두 가지 단점이 있는데, 바로

  • 초기 설정이 까다롭고
  • Access Token이 유출되면 악용될 가능성이 매우 높아지기 때문이다.

이 또한 언젠가 해결해야 하는 문제로 토론이 이루어지고 있으나, 현재까지로는 토큰만 유출 안되면 이론상 완벽하기 때문에 다들 바로 표준으로 채택한 것이다.
따라서 2.0이 2012년에 나왔는데, 현재까지 3.0은 나오지 않은 상태이다.

(4) OAuth 2.0 주요 용어

  • Resource Owner (자원 소유자)
    • 자원의 주인. 일반적으로 사용자를 지칭함
    • ex) Facebook 계정을 가진 사용자
  • Client (클라이언트)
    • 자원 소유자가 허용한 자원에 접근하려는 애플리케이션
    • ex) 자신의 Google Drive에 파일을 업로드하는 서비스
  • Authorization Server (인증 서버)
    • 클라이언트가 인가 코드 또는 토큰을 요청하는 서버
    • 예: Google, Facebook 등
  • Resource Server (자원 서버)
    • 보호된 자원이 저장된 서버
    • 예: Google Drive API 서버
  • Access Token (액세스 토큰)
    • 클라이언트가 자원 서버에 접근할 때 사용하는 임시 키
    • 만료 시간이 있음

(5) OAuth 2.0 작동 방식

출처: GCP 개발 문서

  1. Request token
    • 사용자(클라이언트)는 로그인을 시도함. 이 때 Google이나 Naver같은 소셜 로그인을 선택함 = 사용자는 사용자 권한을 얻기 위해 인증을 받아야함
    • 이때 사용하는 토큰은 업체마다 구현이 다름: 개발문서를 꼭 참고할 것
  2. Authorization code
    • 사용자가 인증 서버에서 로그인을 완료하면, 인증 서버는 Authorization code를 redirect url로 전달함
    • 이 때 code는 임시로, 시간이 지나면 다시 재발급을 받아야 함
  3. Exchange code for token & Token response: code를 이용해서 curl 요청을 보냄으로써 Access token을 발급함
  4. Use token to call API
    • API를 요청할 때, Access token을 사용해서 사용자 정보를 인증함
    • 설명을 위해 로그인을 예시로 들었기 때문에, 여기서는 login API가 사용될 것이고 인증이 잘 됐다면 바로 로그인이 될 것임

Author: Ruby Kim
Reprint policy: All articles in this blog are used except for special statements CC BY 4.0 reprint policy. If reproduced, please indicate source Ruby Kim !
Comments
 Previous
[오픈소스] 2024년 8월 오픈소스 소식지 (2): RouteLLM, 비전 언어 모델, Tau, AuraFlow, gpu.cpp, Github 서버 다운 [오픈소스] 2024년 8월 오픈소스 소식지 (2): RouteLLM, 비전 언어 모델, Tau, AuraFlow, gpu.cpp, Github 서버 다운
전 세계의 오픈소스 소식을 톺아보자: 24년 8월 (2): RouteLLM, 비전 언어 모델, Tau, AuraFlow, gpu.cpp, Github 서버 다운
Next 
[오픈소스] 2024년 8월 오픈소스 소식지 (1): Xpra, Rye, DB Browser for SQLite (DB4S), Crawlee for Python, AMD의 Silo AI 인수, Zed [오픈소스] 2024년 8월 오픈소스 소식지 (1): Xpra, Rye, DB Browser for SQLite (DB4S), Crawlee for Python, AMD의 Silo AI 인수, Zed
전 세계의 오픈소스 소식을 톺아보자: 24년 8월 (1): Xpra, Rye, DB Browser for SQLite (DB4S), Crawlee for Python, AMD의 Silo AI 인수, Zed
  TOC