OAuth 학습 정리

 

Web을 지탱하는 기술 중 하나인 OAuth

Restful API가 서로 다른 두 애플리케이션 간 데이터를 간편하게 전달하기 위해 만든 관례라면, 

OAuth는 데이터를 간편하고 안전하게 주고받기 위해 만들어진 표준이라고 한다. 

 

OAuth는 ID, 비밀번호 대신 Access token을 기반으로 사용자를 식별한다

• 이 토큰은 API를 제공하는 Resource server만 발급할 수 있다.
• 일정 시간이 지나면 폐기될 수 있다. 
• 모든 토큰은 필요한 권한만 지니게 할 수 있어서 서버는 클라이언트의 접근 권한을 쉽게 제어할 수 있다. 
  • 예를 들어, 페이스북 API를 사용할 때 "읽기 권한"만 가진 Access token을 만들 수 있다. 모바일 앱이 페이스북 인증을 지원하고 읽기 전용 토큰만 사용한다면 이 앱은 tocken으로 페이스북 글을 게시할 수는 없다. 
  • 페이스북 인증을 사용하는 모바일 앱은 사용자의 ID, 비밀번호가 필요하지 않다. 사용자가 페이스북 페이지에서 로그인하면 페이스북은 모바일 앱에 사용자가 승인한 권한만 있는 Access token을 전달한다. 
  • API를 사용하는 모바일 앱이 해킹당해도 권한 도용으로 인한 손실을 최소화할 수 있다. 필요하다면 Access token을 즉각 폐기처리 할 수도 있다.
  • 플랫폼에 상관없에 API의 접근 제한을 쉽게 할 수 있다

 

OAuth 1.0a vs 2.0

• OAuth 표준은 현재 1.0a와 2.0 두 가지 버전이 있다. 이 둘의 방식 차이를 비교해 보자. 

 

OAuth 1.0a

• API를 사용하는 클라이언트가 필요한 권한을 가지고 있는지 확인한다. 
• Access token을 획득한 방법까지 알 수 있기 때문에 인증(자신을 증명하는 일)과 인가(권한을 확인하는 일) 역할을 모두 수행한다. 그래서 2.0보다 더 안전하다고 볼 수 있다. 
• 그러나 OAuth 2.0에 비해 인증 과정이 복잡하다.
  • 표준에서 요구하는 서명, request token 등 여러 보안 요소들을 직접 구현해야 해서 별도의 라이브러리가 있더라도 직접 구현하는 데 시간이 필요하다. 

 

OAuth 2.0

• 1.0a에 있는 인증 절차가 삭제되고 인가 절차만 남아 1.0a보다 구조가 간단하며 사용하기 쉽다. 
• 그러나 권한을 확인하는 데 사용할 Access token을 어떻게 얻는지 확인할 방법이 없어서 가로채기 형태의 공격에 취약하다. 
• 가장 간편한 보완책 중 하나는 HTTPS 위에서 OAuth 2.0을 사용하는 것이다. 
  • 메시지가 암호화되므로 가로채기 공격을 막을 수 있다. 
  • 그러나 상황에 따라 액세스 토큰 만료 시간을 분 단위로 줄이거나 액세스 토큰을 발급한 IP만 토큰 사용이 가능하게 만드는 등의 더욱 강력한 보안 정책이 필요할 수도 있다.