어플리케이션

OAuth(Open Authorization)에 대해 알아보겠습니다.

forward error correction Circle 2024. 11. 27. 04:55
반응형

Ⅰ. OAuth(Open Authorization) 란? 

 사용자 인증 및 권한 부여를 처리하기 위한 표준 프로토콜입니다. 주로 애플리케이션 간에 보안 방식으로 자원(데이터 또는 서비스)에 접근 권한을 부여할 때 사용됩니다. 이를 통해 사용자는 자신의 자격 증명(예: 비밀번호)을 제공하지 않고도 타사 애플리케이션에 특정 자원에 대한 접근 권한을 안전하게 부여할 수 있습니다.

OAuth를 사용하면 사용자는 한 플랫폼에서 로그인한 다음 다른 플랫폼에서 작업을 수행하고 데이터를 볼 수 있는 권한을 부여받을 수 있습니다. OAuth는 SSO(Single Sign-On) 서비스에서 다른 클라우드 애플리케이션으로 권한 부여를 전달하는 데 사용되는 가장 일반적인 방법 중 하나입니다.

Ⅱ. OAuth 프로세스

 ⅰ. 리소스 소유자(Resource Owner)
     : 데이터를 소유한 사용자입니다.

       Ex) Google 계정의 이메일 데이터를 가진 사용자.
 ⅱ. 리소스 서버(Resource Server)
     : 데이터를 호스팅하고 관리하는 서버입니다. 

       Ex) Google API.
 ⅲ. 클라이언트(Client)
     : 리소스 소유자의 데이터를 요청하는 애플리케이션입니다. 

        Ex) 예를 들어, 타사 이메일 클라이언트.
 ⅳ. 권한 부여 서버(Authorization Server)
     : 리소스 소유자를 인증하고 접근 권한(Access Token)을 부여하는 서버입니다.
        Ex) Google의 OAuth 서버.

Ⅲ. OAuth 구성요소

 ⅰ. 액세스 토큰(Access Token)
리소스 서버에 접근할 수 있는 임시 토큰으로, 클라이언트가 사용자의 데이터에 접근하는 데 사용됩니다. 일반적으로 만료 시간이 설정됩니다.
 ⅱ. 리프레시 토큰(Refresh Token)
액세스 토큰이 만료된 경우, 새 액세스 토큰을 발급받는 데 사용되는 토큰입니다.
 ⅲ. 승인 코드(Authorization Code)
권한 부여 서버가 클라이언트에게 제공하는 임시 코드로, 이를 통해 액세스 토큰을 교환할 수 있습니다.

Ⅳ. OAuth 동작 원리

 일반적으로 가장 많이 사용되는 방식은 Authorization Code Flow입니다.

ⅰ. Authorization Code Flow
    1) 사용자 인증 요청
      : 클라이언트 애플리케이션이 권한 부여 서버에 인증 요청을 보냅니다.
       ▶ 사용자 브라우저가 리소스 소유자 인증 화면으로 리디렉션됩니다.
       ▶ 사용자는 자신의 자격 증명(예: 아이디, 비밀번호)으로 로그인하고 권한을 부여합니다.
    2) 승인 코드 발급
      : 사용자가 권한을 부여하면, 권한 부여 서버는 승인 코드를 클라이언트 애플리케이션에 전달합니다.
    3) 액세스 토큰 요청
      : 클라이언트는 승인 코드를 사용해 권한 부여 서버에 액세스 토큰을 요청합니다.
       ▶ 이 과정에서 클라이언트 ID와 클라이언트 비밀 키가 필요합니다.
    4) 액세스 토큰 발급
      : 권한 부여 서버는 요청을 확인하고, 클라이언트에게 액세스 토큰을 발급합니다.
    5) 리소스 서버 요청
      : 클라이언트는 액세스 토큰을 사용해 리소스 서버에서 데이터에 접근합니다.

ⅱ. Implicit Flow
브라우저 기반 애플리케이션에서 주로 사용되며, 승인 코드 단계 없이 액세스 토큰을 직접 발급받습니다. 보안성이 낮아 현재는 권장되지 않습니다.

Ⅴ. OAuth의 장점

ⅰ. 보안성
   : 사용자 자격 증명을 공유하지 않고도 안전하게 권한을 부여할 수 있습니다.
ⅱ. 범용성
   : 다양한 서비스와 애플리케이션에서 쉽게 통합 가능.
ⅲ. 사용자 경험 향상
   : 사용자가 비밀번호를 여러 애플리케이션에 반복 입력할 필요가 없습니다.

Ⅵ. OAuth의 한계 및 해결 방안

ⅰ. 클라이언트 보안 이슈
   1) 클라이언트 비밀 키 노출 위험이 있음.
       ▶ PKCE(Proof Key for Code Exchange)를 사용하여 보안 강화.
ⅱ. 토큰 탈취 위험
   1) 네트워크 중간 공격으로 액세스 토큰이 탈취될 수 있음.
       ▶ HTTPS를 사용하고, 토큰 수명을 짧게 설정.
ⅲ. 사용자 프라이버시 보호
   1) 과도한 권한 요청은 사용자 불신을 초래할 수 있음.
       ▶ 최소 권한 요청(Least Privilege) 원칙 준수.

 

Ⅶ. OAuth 2.0과 OAuth 1.0의 차이

  OAuth 1.0 OAuth 2.0
인증방식 서명 기반 인증 사용 단순화된 토큰 기반 인증 방식 사용
구성 요소 이용자
사용자
서비스 제공자
자원 소유자
클라이언트
권한 서버
자원 서버
구현 방식 구현이 복잡하며 현재는 거의 사용되지 않음 클라이언트와 서버 간 통신이 더 효율적이며, 확장성이 뛰어남

Ⅷ. OAuth 사용 사례

 ⅰ. 이커머스 및 소셜 로그인
    : Kakao, Apple 계정을 사용하여 다른 웹사이트에 로그인.
 ⅱ. 타사 애플리케이션 연동
    : 이메일, 캘린더, 클라우드 파일 등을 타사 애플리케이션과 공유.
 ⅲ. IoT 기기 인증
    : 스마트 기기가 사용자 계정을 인증하고 데이터에 접근

반응형