OAuth 2.0은 자신이 소유한 리소스에 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 프로토콜이라고 함..
OAuth 토큰은 발렛 키처럼 클라이언트의 접근 권한을 리소스 소유자가 허용한 범위로 제한할 수 있다고 함.
OAuth는 한 시스템이 다른 시스템의 어떤 구성 요소에 대한 접근 권한을 얻을 수 있게 해주는 것.
OAuth 2.0 프레임워크는 리소스 소유자를 대신해 HTTP 서비스와 리소스에 대한
접근 요청 승인을 조정하거나
리소스 소유자를 대신해 서드파티 애플리케이션에게 리소스에 대한 접근을 허용해주는 방식으로
HTTP 서비스에 대한 서드파티 애플리케이션의 접근을 가능하게 해준다...
책의 예시 상황
사진 저장 서비스(회사 A), 사진 인화 서비스(회사 B)가 있음.
저장 사이트에 사진을 업로드했고, 인화하고 싶다.
그런데 두 서비스는 다른 회사가 제공하여 계정이 연동되지 않는다.
리소스 소유자는 인화 서비스에 사진 접근 권한을 위임해줘야 하는데, 사진에 대한 접근을 완전히 위임하지 않고 제한하고 싶은 상황.
LDAP (Lightweight Directory Access Protocol)
LDAP를 이용하면 클라이언트 애플리케이션은 사용자로부터 자격 증명을 직접 수집한다고 함..
사용자에 대한 "중간자 공격"의 한 형태라고 볼 수 있다고 함...
개발자 키를 클라이언트에 발급하고, 클라이언트는 그것을 이용해 보호된 리소스를 직접 요청하는 방법도 있다고 함...
서드파티 서비스에 공유할 목적으로만 사용되는 특별한 비밀번호를 사용자에게 발급하는 방법도 있다고 함...
위 과정에서 리소스 소유자의 자격 증명이 클라이언트에게 노출되지 않았다??
리소스 소유자가 인가 서버에 인증하는 것과 별개로 클라이언트와 인가 서버가 통신?
OAuth의 힘은 권한 위임이라는 개념이라고 함..
인가 프로토콜로 불리지만, 권한 위임 프로토콜이라고 할 수 있다고 함.
예를 들어, 사진 인화 서비스가 유저에게 사진 저장 사이트 접근 요청.
사진 저장 사이트는 인화 서비스가 요청한다고 유저에게 알리고 승인여부 요청.
유저가 승인하면 인화 서비스에게 저장 서비스 접근 권한을 위임하게 됨.
OAuth 시스템은 주로 TOFU 원칙(Trust, On First Use)을 따른다고 함..
보안적 결정이 런타임에 사용자에게 요구되는 걸 말함.. 처음 한번 사용할 때만 신뢰 여부 결정.
인가 서버
클라이언트
OAuth2의 확장성과 모듈화는 가장 큰 장점 중 하나라고 함..
구현할 때 보안 취약점들이 있다고 함.
RFC 6819 - OAuth Threat Model Document
토큰을 얻는 방법, 사용 방법이 OAuth의 기본적인 부분이라고 함.
OAuth는 Http와 독립적으로 정의되지 않는다?
TLS 같은 안전한 전송 계층 매커니즘의 도움이 필요하다고 함... (HTTPS)
OAuth는 인증 프로토콜이 아니다.
누구인지 알 필요없고, 허락해줬다는게 중요하다고 함..
OAuth는 토큰의 포맷을 결정하지 않는다고 함..
근데 편의를 위해 JWT, token introspection 프로토콜의 개발로 이어졌다고 함.
OAuth2는 암호화 방법을 정의하지 않는다고 함..
JOSE?
OAuth는 웹 API를 보호하기 위해 사용되는 보안 프로토콜이다?
(로그인 대신해주던걸로만 알고있었는데...)
등장 인물들 헷갈림
애플리케이션, 리소스 소유자
리소스 소유자가 누구 말하는거?, 리소스가 어떤 리소스 말하는거?
중간자 공격(Man In The Middle Attack) 잘 모름.
사용자가 토큰을 관리하는 방식 vs OAuth 프로토콜에서 클라이언트가 토큰을 관리하는 방식
OAuth는 원래 API를 사용하기 위해 설계됐으며, 주요 상호 작용은 웹 브라우저 밖에서 이뤄진다?
클라이언트의 자격 증명이 정확히 어떤 것?
OAuth에서 클라이언트가 침해되더라도 리소스 소유자의 자격 증명 데이터는 유출되지 않는다?
(애초에 그것을 사용하지 않는다고 함.)
메시지 시그니처?