OAuth 정리

OAuth

데이터를 간편하고 안전하게 주고받기 위한 표준. ID와 비밀번호 대신 Access Token으로 사용자를 식별한다.

• 토큰은 API를 제공하는 리소스 서버만 발급할 수 있으며, 일정시간이 지나면 폐기할 수 있다.
• 토큰마다 필요한 권한만 부여할 수 있으므로, 서버가 클라이언트의 접근권한을 쉽게 제어할 수 있다.

ex) 페이스북 API를 사용하는 모바일 앱의 경우

1. Read Only 권한을 지닌 Access Token을 생성할 수 있다. 모바일 앱이 페이스북 인증을 지원할 때 이 토큰만 발급받는다면, 해당 모바일 앱 사용자는 페이스북에 글을 게시할 수 없다.
2. 사용자 ID와 비밀번호가 필요하지 않다. 페이스북 페이지에서 로그인하면, 페이스북 측에서 해당 모바일 앱에 사용자가 승인한 권한만 있는 토큰을 발급해 전달해주기 때문
3. API를 사용하는 모바일 앱이 해킹당해도 권한 도용으로 인한 손실을 최소화할 수 있다. 해당 토큰을 즉각 폐기하는 식으로도 빠른 조치가 가능

작동방식과 용어

OAuth는 1.0a, 2.0 두 가지 버전이 있지만, 이름만 같을 뿐 작동방식은 판이하게 다르다.

• 1.0a

  • api를 사용하는 클라이언트가 '필요한 권한을 가지고 있는지' 확인하며, Access Token을 획득한 방법까지 알 수 있다.
  • 즉 자신을 증명하는 인증 + 권한을 확인하는 인가 작업을 모두 수행함. 따라서 2.0보다 안전함
  • 2.0에 비해 인증과정이 복잡하고, 표준에서 요구하는 Signature, request Token 등의 보안요소를 직접 구현해야 하므로 완성시간이 오래걸림

• 2.0

  • 1.0a에 있는 인증절차가 삭제되고, 인가 절차만 있어서 사용이 쉬움
  • but 권한을 확인하는 데 사용할 Access Token을 어디서 얻었는지 확인할 방법이 없음 = 가로채기 공격에 취약함
  • 제거된 인증기능을 보완할 방법이 개발자의 책임.
    • 대표적인 보완책 중 하나가 HTTPS + OAuth 2.0. HTTPS의 암호화를 활용해 가로채기 공격을 막는 것
    • 상황에 따라 Access Token의 유효기간을 분 단위로 줄이거나, 발급한 IP주소에서만 토큰사용이 가능하도록 만드는 등의 강화된 보안정책을 적용하기도 함

용어

• 인증 (authenticaiton) : 자신이 누구라고 주장하는 사람을 확인하는 절차

• 권한부여 (인가) (authorization) : 요구하는 정보나 리소스에 접근할 수 있도록 허용하는 것

• Resource Owner : 리소스 서버에서 제공하는 기능을 실제로 사용할 주체. ID와 비밀번호로 리소스 클라이언트에게 권한을 인가하여 Access Token을 얻게 될 주체. 단순히 생각하면 실 사용자. End User라고도 한다.

• Resource Client : resource owner에게서 사용 인가를 받아, 소유자 대신 Access Token을 획득한 뒤 해당 토큰으로 리소스 서버의 api를 사용하는 주체.

  • 페이스북이나 구글 인증기능을 사용하는 다양한 모바일 앱, 웹서비스를 의미함.
  • End User의 인가가 있어야 한다. (사용자가 정보를 입력해야 인증서버에 토큰을 요청할 수 있으니)

cf. 실무에서는 인가 서버 (Authorization) 가 인증서버 (Authentication) 기능을 겸하는 경우가 많음. OAuth2.0에서는 Authorization 서버라고 보는 게 맞다.

• Resource Server : 보호된 리소스를 관리하며, 리소스 클라이언트가 사용할 API를 관리하는 주체. Access Token을 요구하며, Access Token의 유효성을 확인하기 위해 인가 서버와 통신을 주고받기도 한다.

cf. API 호출할 때마다 토큰의 유효성을 확인하면 Authorization 서버의 부하가 커져서 비효율적이다. 이를 보완하기 위해 Authorization 내역을 캐싱하거나, 토큰 자체에 Authorization 내역을 확인할 수 있는 JWT를 사용하기도 한다.

과정

1. Authorization 요청. 리소스 클라이언트가 resource owner에게
   • sns로그인 기능에서 모바일 앱이 사용자에게 로그인을 요청하는 것과 같은 맥락
2. Authorization 코드 획득 + access token 요청
   • sns서버 (페이스북, 구글 등)에서 authorization을 요청했던 모바일 앱으로 authorization code를 전달한다.
   • 공식 SDK (ex. 페이스북 SDK)를 활용하면 access token을 바로 획득할 수도 있음
   • authorization code를 받은 경우, 모바일 앱 측에서 해당 코드를 access token으로 변환하는 작업을 해야 한다
   • 모바일 앱 측에서는 토큰을 받은 뒤, 해당 토큰이 적절한 권한 scope를 가지고 있는지 확인하기도 한다.
3. Secured Resource 요청
   • 발급받은 Access token을 활용해서 api 요청.

사용 시 주의점

Resource Owner

• 리소스 클라이언트 (모바일 앱)가 필요 이상의 권한을 요청하지는 않는지 확인해야 한다.
• 올바른 권한요청은 GDPR 기준 충족을 위한 조건 중 하나이기도 함
• 개발과정에서야 편의성을 위해 권한을 포괄적으로 부여하지만, 서비스 출시 시에는 사용자가 직접 필요한 권한만 체크해서 access token을 생성할 수 있어야 한다.

Resource Client

• 발급받은 토큰이 외부로 유출되지 않도록 주의해야 함. 유효기간을 짧게 설정하고 자주 갱신해야 함
• 만료된 토큰을 사용하지 않도록 유의. 만료된 토큰을 사용해서 서비스가 먹통이 되는 상황이 발생하지 않도록
  • 클라이언트 내부 DB에 저장된 토큰이 있는 경우, 토큰 유효성 검사
• 공식 SDK 사용하기. Access Token을 발급받는 방법 중 하나가 SDK인데, SDK는 보안패치 / authorization code 없이 token을 사용하거나 토큰을 자동 갱신하는 등의 편의성을 제공하며 업데이트하기 때문
• Client Id / Secret 관리하기
  • 모바일 앱이 sns로그인 기능을 사용하려면, 해당 sns서비스에 사전허가를 받아야 함. 허가를 받을 경우 sns서비스에서 사용할 수 있는 client Id / Secret을 할당받게 되고, 이게 있어야 서비스 사용이 가능하다.
  • 반드시 파일로부터 읽어들어야 하는 값이며, 소스코드나 repository에 포함해선 안 됨
• HTTPS 사용. restful api로 토큰을 받는 경우, 가로채기 공격을 막기 위해 필요하다. (SDK 사용 시에는 해당없음)

Resource Server (OAuth 2.0 직접구현 시)

• 토큰의 권한 검사하기. 해당 토큰이 유효한지 authorization server에 요청을 보내 확인해야 한다. 서버 부하가 클 경우 JWT처럼 토큰 자체적으로 authorization 정보를 보유한 형태를 사용한다.
• 데이터 검증. 클라이언트에게서 받은 모든 데이터는 신뢰할 수 없다. 문자열은 escape를 거쳐야 하고, 브라우저의 경우 content-type은 application/json으로 설정해야 한다.

Authorization Server (OAuth 2.0 직접구현 시)

• 토큰관리. 재사용을 막기 위해 최대한 짧은 만료시간. 만료시간이 짧을수록 토큰 생성을 해야 하므로 서버 부하도 커진다.
• 리소스 클라이언트의 응답처리. 요청 주소(request url)과 토큰을 실제 클라이언트로 전달할 응답주소(return url)이 일치하는지 확인해야 한다. 이게 다르면 해킹시도로 간주할 수 있음.
• 에러를 리턴해야 할 때, 가급적이면 정보노출을 최소화.

유의점

OAuth 2.0은 Authentication이 아니라 Authorization을 제공하는 표준. 하지만 authentication 서버를 만드는 것도 불가능한 건 아니다.

 

 

사진 출처

https://www.ateam-oracle.com/implementing-oauth-2-with-oracle-access-manager-oauth-services-part-iii

 

출처

학교에서 알려주지 않는 17가지 실무 개발 기술 국내도서 저자 : 이기곤 출판 : 한빛미디어 2020.04.16 상세보기