[면접 준비] OAuth에 대해서 설명해주세요. (24/04/02)

OAuth (2.0)

구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트가 사용자의 접근 권한을 위임(Delegated Authorization, 권한 부여)받을 수 있는 표준 프로토콜입니다.

쉽게 말하자면, OAuth를 사용하여 서비스 이용자가 타사 플랫폼 정보에 접근하기 위해 권한을 위임받는 것을 말한다.

(구글, 카카오 로그인 등을 생각하면 될듯 하다.)

 

주요 구성 요소

1. 주체(또는 역할)
   
   • Resource Owner
     • 리소스 소유자 또는 사용자. 구글, 페이스북 등의 플랫폼에서  리소스를 소유하고 있는 사용자.
     • 구글, 페이스북 등을 사용하여 서비스에 접근하려 하는 유저로, OAuth 2.0는 사용자의 승인을 반드시 필요로 한다.
   • Authorization & Resource Server
     • Authorization Server : 클라이언트가 사용자 데이터에 접근할 수 있도록 인증을 제공한다. 승인을 받은 클라이언트에게 접근 토큰을 발행하며, 이 토큰은 클라이언트가 리소스 서버에 접근할 때 사용된다.
     • Resource Server : 사용자의 데이터(리소스)를 저장하는 곳으로, 클라이언트가 이 서버를 통해 데이터에 접근한다. 서버는 클라이언트의 요청을 받아 인증 서버로부터 받은 접근 토큰을 검증하고, 통과한 요청에 대해서만 데이터를 제공.
   • Client
     • 사용자의 리소스에 접근하려는 서비스. 사용자의 명시적 승인을 통해 사용자의 리소스에 접근할 권한을 얻는다. (ex:구글 로그인 동의 페이지의 사용자 정보 제공 동의 항목)
2. 권한부여 방식
   • 권한 부여 승인 코드 방식(Authorization Code Grant)
     • 보편적으로 사용되는 방식으로, 리다이렉션을 통해 사용자 인증과 인가를 처리하며, 사용자가 신뢰할 수 있는 서버에서 인증을 받게 된다.
     • 인증요청 - 인증 - 인가 - 인증 코드 발급 - 액세스 토큰 요청 - 액세스 토큰 발급
     • 사용자 자격증명이 클라이언트에서 노출되지 않게 하여 사용자 로그인 정보를 보호한다.
   • 암묵적 승인 방식(Implicit Grant)
     • 클라이언트 사이드 어플리케이션에서 사용되며, 권한 부여 승인 코드 방식보다 간단하지만, 액세스 토큰이 클라이언트에서 노출되므로 보안적으로 문제가 될 수 있다.
     • 인증 요청 - 인증 - 인가 - 토큰 발급 - 리소스 요청
     • 인증 코드 교환 단계가 없으므로 상대적으로 빠르지만, 토큰이 브라우저를 통해 직접 전달되므로 CSRF(Cross-Site RequestForgery)등의 공격에 취약할 수 있기 때문에 보안을 강화하거나 다른 인증 흐름 사용이 요구된다.
   • 자원 소유자 자격증명 승인 방식(Resource Owner Password Credentials Grant)
     • 사용자(리소스 소유자)의 ID와 비밀번호를 직접 사용하여 인증하는 방식으로, 신뢰할 수 있는 어플리케이션에서만 사용되어야 한다.(사용자의 비밀번호를 직접 제공해야 하기 때문)
     • 인증 요청 - 토큰 요청 - 토큰 발급
     • 비밀번호 변경 등의 보안 조치가 취해져야 하는 상황에서 문제가 될 수 있다.(비밀번호 재 등록 등.)
   • 클라이언트 자격증명 승인 방식(Client Credentials Grant)
     • 클라이언트 자체 자격 증명을 사용하여 액세스 토큰을 얻는 방법. 별도의 리소스 소유자의 동의나 인증 없이 서비스를 요청할 때 유용, 클라이언트 서비스가 사용자를 대신하여 사용하는 경우 사용된다.
     • 토큰 요청 - 토큰 발급
     • 장점 : 별도 인증 과정이 필요 없다 / 단점 : 사용자의 리소스에 대한 액세스 권한을 제공할 수 없다.
     • 클라이언트가 직접 리소스를 소유하거나 사용자 개입이 필요없는 서비스에서 사용.
3. 장단점
   
   • 장점
     • 보안 : 사용자는 자신의 아이디와 비밀번호를 직접 공유하지 않고 서비스 접근 권한을 부여할 수 있다.
     • 유연성 : 다양한 유형(웹,모바일)을 지원하며, 다양한 시나리오에 맞게 설정할 수 있다.
     • 사용자 경험 : 한 번 로그인으로 정보 제공이 끝나기 때문에, 다시 로그인할 필요가 없어진다.
   • 단점
     • 복잡성 : 기술적으로 복잡하다. 적절한 보안 지침 준수와 테스트, 유지 보수에 시간과 노력을 투자해야 한다.
     • 보안 취약점 : 잘못 구현된 시스템은 공격자가 인증 토큰을 가로채는 등의 취약점이 될 수 있다.
     • 중앙집중식 : 사용자가 신뢰하는 서비스가 인증 과정을 처리함으로서, 대형 서비스들이 사용자 데이터에 대한 통제력을 가지게 된다.

답변

OAuth는 사용자 자격 증명을 공유하지 않고도 위임된 인증을 통해 타사 클라이언트가 Google 및 Facebook과 같은 플랫폼의 사용자 데이터에 액세스할 수 있도록 하는 프로토콜입니다. 이는 다양한 역할과 인증 방법을 포함하여 유연성과 간소화된 사용자 경험을 제공하지만 보안 취약성을 방지하려면 신중한 구현이 필요합니다. 

 

 

+

OAuth 1.0에 대한 내용의 경우, 어떤 불편한점이 있었는지 이를 개선하기 위해 2.0에서 어떤 발전이 있었는지 등에 대한 언급을 추가해보자.

(1.0에서는 토큰 갱신이 어려웠다. 서명된 요청을 사용하여 사용자를 인증했다. 웹 기반 어플에서 주로 사용됐다. 승인 절차가 두단계였다 

2.0에서는 쉽게 새 토큰을 발급하고 갱신, 토큰을 사용하여 사용자 인증, 범용적 프로토콜(모바일,웹), 승인 절차가 단순해졌다. -> 2.0이 더 유연하고 보안성이 높은 프로토콜이다.)

+

OAuth가 "왜" 나왔는지.

( 직접 고객의 다른 플랫폼 아이디와 비밀번호를 받아 로그인을 한다? -> 문제가 발생할 수 있다. 안전하지 못하다.)