[OAuth 2.0] 1. 개요

• 참고자료: OAuth2 In Action

OAuth 2.0이란

• OAuth 2.0은 자신이 소유한 리소스에 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 프로토콜이라고 함..

  1. 어떤 애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한 요청.
  2. 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근.

• OAuth 토큰은 발렛 키처럼 클라이언트의 접근 권한을 리소스 소유자가 허용한 범위로 제한할 수 있다고 함.

• OAuth는 한 시스템이 다른 시스템의 어떤 구성 요소에 대한 접근 권한을 얻을 수 있게 해주는 것.

  OAuth 2.0 프레임워크는 리소스 소유자를 대신해 HTTP 서비스와 리소스에 대한
  접근 요청 승인을 조정하거나
  리소스 소유자를 대신해 서드파티 애플리케이션에게 리소스에 대한 접근을 허용해주는 방식으로
  HTTP 서비스에 대한 서드파티 애플리케이션의 접근을 가능하게 해준다...

• 구성 요소
  2장에서 자세히 다룬다고 함.
  핵심은 OAuth를 통해 클라이언트가 리소스 소유자 대신 보호된 리소스에 대한 접근 권한을 획득하는 거라고 함..
  

• 책의 예시 상황
  사진 저장 서비스(회사 A), 사진 인화 서비스(회사 B)가 있음.
  저장 사이트에 사진을 업로드했고, 인화하고 싶다.
  그런데 두 서비스는 다른 회사가 제공하여 계정이 연동되지 않는다.
  리소스 소유자는 인화 서비스에 사진 접근 권한을 위임해줘야 하는데, 사진에 대한 접근을 완전히 위임하지 않고 제한하고 싶은 상황.

  • 리소스: 사진 저장 사이트의 API
  • 저장 API의 클라이언트?: 인화 서비스
  • 리소스 소유자: 유저

자격 증명 공유

• 사용자의 자격 증명을 그대로 저장해 이용하는 것은 위험해서 한정된 상황에서만 사용해야 한다고 함...

LDAP (Lightweight Directory Access Protocol)
LDAP를 이용하면 클라이언트 애플리케이션은 사용자로부터 자격 증명을 직접 수집한다고 함..
사용자에 대한 "중간자 공격"의 한 형태라고 볼 수 있다고 함...

• 개발자 키를 클라이언트에 발급하고, 클라이언트는 그것을 이용해 보호된 리소스를 직접 요청하는 방법도 있다고 함...

• 서드파티 서비스에 공유할 목적으로만 사용되는 특별한 비밀번호를 사용자에게 발급하는 방법도 있다고 함...

접근 권한 위임

• OAuth는 유저가 보호된 리소스에 대한 자신의 접근 권한 일부를 클라이언트 애플리케이션에게 위임하기 위해 설계된 프로토콜이라고 함.
  이를 위해 OAuth 시스템에는 Authorization Server(인가 서버)가 포함된다고 함.

• 위 과정에서 리소스 소유자의 자격 증명이 클라이언트에게 노출되지 않았다??
  리소스 소유자가 인가 서버에 인증하는 것과 별개로 클라이언트와 인가 서버가 통신?

• OAuth의 힘은 권한 위임이라는 개념이라고 함..
  인가 프로토콜로 불리지만, 권한 위임 프로토콜이라고 할 수 있다고 함.

  예를 들어, 사진 인화 서비스가 유저에게 사진 저장 사이트 접근 요청.
  사진 저장 사이트는 인화 서비스가 요청한다고 유저에게 알리고 승인여부 요청.
  유저가 승인하면 인화 서비스에게 저장 서비스 접근 권한을 위임하게 됨.

• OAuth 시스템은 주로 TOFU 원칙(Trust, On First Use)을 따른다고 함..
  보안적 결정이 런타임에 사용자에게 요구되는 걸 말함.. 처음 한번 사용할 때만 신뢰 여부 결정.

OAuth 2의 장단점

• 인가 서버

  • 클라이언트를 여러 신뢰 레벨로 분류 가능?
  • 복잡성이 클라이언트에서 서버로 이동한다?
  • 모든 클라이언트와 유저의 자격 증명과 토큰을 관리해야 한다고 함..

• 클라이언트

  • 단지 클라이언트의 자격증명?과 토큰을 안전하게 관리하면 된다고 함.

• OAuth2의 확장성과 모듈화는 가장 큰 장점 중 하나라고 함..

• 구현할 때 보안 취약점들이 있다고 함.
  RFC 6819 - OAuth Threat Model Document

OAuth2가 아닌것?

• 토큰을 얻는 방법, 사용 방법이 OAuth의 기본적인 부분이라고 함.

• OAuth는 Http와 독립적으로 정의되지 않는다?
  TLS 같은 안전한 전송 계층 매커니즘의 도움이 필요하다고 함... (HTTPS)

• OAuth는 인증 프로토콜이 아니다.
  누구인지 알 필요없고, 허락해줬다는게 중요하다고 함..

• OAuth는 토큰의 포맷을 결정하지 않는다고 함..
  근데 편의를 위해 JWT, token introspection 프로토콜의 개발로 이어졌다고 함.
  

• OAuth2는 암호화 방법을 정의하지 않는다고 함..
  JOSE?

질문들

• OAuth는 웹 API를 보호하기 위해 사용되는 보안 프로토콜이다?
  (로그인 대신해주던걸로만 알고있었는데...)

• 등장 인물들 헷갈림
  애플리케이션, 리소스 소유자
  리소스 소유자가 누구 말하는거?, 리소스가 어떤 리소스 말하는거?

• 중간자 공격(Man In The Middle Attack) 잘 모름.

• 사용자가 토큰을 관리하는 방식 vs OAuth 프로토콜에서 클라이언트가 토큰을 관리하는 방식

• OAuth는 원래 API를 사용하기 위해 설계됐으며, 주요 상호 작용은 웹 브라우저 밖에서 이뤄진다?

• 클라이언트의 자격 증명이 정확히 어떤 것?

• OAuth에서 클라이언트가 침해되더라도 리소스 소유자의 자격 증명 데이터는 유출되지 않는다?
  (애초에 그것을 사용하지 않는다고 함.)

• 메시지 시그니처?