- 자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜
- 애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한을 허용하고, 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근하는 프로토콜
역사
- 여러 웹 서비스를 연계하여 사용토록 하기 위해 OpenID 이용
- API 접근 권한 관리를 위해 구글의 AuthSub, 야후의 BBAuth 등을 참고하여 OAuth 1.0 개발
- OAuth의 세션 고정 공격을 보완한 OAuth 1.0a 개발
- OAuth 1.0a는 IETF에서 RFC 5849로 정리됨
- OAuth 커뮤니가 성장하여 여러 메커니즘에 대한 논의 시작
- OAuth의 구조적인 문제점을 해결하고, 핵심요소만을 차용한 유사 프로토콜 WRAP(Web Resource Access Protocol) 발표
- WRAP을 기반으로 OAuth 2.0 개발(RFC 6749, RFC 6750)
- OAuth 2.0은 메커니즘이 하나로 통일되지 않아 4가지 타입으로 발표됨
관련 표준
- [rfc:6749 RFC6749 "OAuth 2.0"]
- [rfc:6749 RFC6750 " The OAuth 2.0 Authorization Framework: Bearer Token Usage"]
- [rfc:7519 RFC7519 "JSON Web Token (JWT)"]
- [rfc:7636 RFC7636 "Proof Key for Code Exchange by OAuth Public Clients"]
구성과 종류
구성
- 리소스 소유자: API에 대한 권한을 가지고 있으며, 이를 위임할 수 있는 이용자
- 보호된 리소스: 리소스 소유자가 접근하는 대상
- 클라이언트: 리소스 소유자를 대신해 보호된 리소스에 접근하는 소프트웨어 등
- 인가 서버: 리소스에 접근할 수 있는 접근 토큰을 발급
프토토콜 종류
| 종류(Type) | 설명 |
|---|---|
| 인가 코드 승인
(Authorization Code Grant) |
|
| 암묵적 승인
(Implicit Grant) |
|
| 리소스 소유자 암호 자격 승인
(Resource Owner Password Credentials Grant) |
|
| 클라이언트 자격 승인
(Client Credentials Grant) |
|
인증 절차
권한 부여 코드 승인
암시적 승인
리소스 소유자 암호 자격 증명
클라이언트 자격 증명
구성
| 구분 | 설명 | 비고 |
|---|---|---|
| 자원 소유자 | 요청하고자 하는 자원의 소유자이자, 인증 주체 | 이용자 |
| 클라이언트 | 자원을 필요로 하는 서비스
자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청 |
쇼핑몰 등 |
| 권한 서버 | 인증을 처리하고 권한을 부여하는 서버 | 페이스북
네이버 구글 등 |
| 자원 서버 | 자원을 가지고 있는 서버 | |
| 접근 토큰 | 자원 서버에 자원을 요청할 수 있는 토큰 | 유효기간 존재 |
| 재발급 토큰 | 권한 서버에 접근 토큰을 요청할 수 있는 토큰 | 접근 토큰 유효기간 만료 시 사용 |
OAuth1.0과 OAuth2.0의 차이
| 비교 | OAuth1.0 | OAuth2.0 |
|---|---|---|
| 참여자 구분 |
|
|
| 토큰 |
|
|
| 유효기간 |
|
|
| 클라이언트 |
|
|
문제점
- OAuth를 제공하는 대형 플랫폼 서비스(신뢰된 서비스, 권한 서버, 자원 서버)에 개인의 행태 정보가 지나치게 축적되는 문제
- 국가 기관이 아닌 신뢰된 서비스가 과연 신뢰할 수 있는가?
참고 문헌
- OAuth 2 IN ACTION(에이콘 출판사)