OAuth: Difference between revisions
From IT Wiki
(새 문서: 분류:보안 ;제3의 신뢰 서비스에서 인증 결과를 토큰 기반으로 공유받아 활용하는 개방형 표준 프로토콜 == 인증 절차 == == 구성 == ==...) |
No edit summary |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
[[분류:보안]] | [[분류:보안]] | ||
;자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜 | |||
*애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한을 허용하고, 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근하는 프로토콜 | |||
== | ==역사== | ||
== 문제점 == | *여러 웹 서비스를 연계하여 사용토록 하기 위해 OpenID 이용 | ||
*API 접근 권한 관리를 위해 구글의 AuthSub, 야후의 BBAuth 등을 참고하여 OAuth 1.0 개발 | |||
*OAuth의 세션 고정 공격을 보완한 OAuth 1.0a 개발 | |||
*OAuth 1.0a는 IETF에서 RFC 5849<nowiki/>로 정리됨 | |||
**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에 대한 권한을 가지고 있으며, 이를 위임할 수 있는 이용자 | |||
*'''보호된 리소스''': 리소스 소유자가 접근하는 대상 | |||
*'''클라이언트''': 리소스 소유자를 대신해 보호된 리소스에 접근하는 소프트웨어 등 | |||
*'''인가 서버''': 리소스에 접근할 수 있는 접근 토큰을 발급 | |||
==프토토콜 종류== | |||
{| class="wikitable" | |||
!종류(Type) | |||
!설명 | |||
|- | |||
|인가 코드 승인 | |||
(Authorization Code Grant) | |||
| | |||
*클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용 | |||
*리스소 접근을 위해, 인가 서버에서 받은 권한 코드로 리소스에 대한 엑세스 토큰을 받는 방식 | |||
|- | |||
|암묵적 승인 | |||
(Implicit Grant) | |||
| | |||
*권한 부여 코드 승인 타입과 다르게 권한 코드 교환 단계가 없음 | |||
*엑세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식 | |||
|- | |||
|리소스 소유자 암호 자격 승인 | |||
(Resource Owner Password Credentials Grant) | |||
| | |||
*클라이언트가 암호를 사용하여 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식 | |||
|- | |||
|클라이언트 자격 승인 | |||
(Client Credentials Grant) | |||
| | |||
*클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식 | |||
|} | |||
==인증 절차== | |||
===권한 부여 코드 승인=== | |||
[[파일:Authorization Code Grant Type.png]] | |||
===암시적 승인=== | |||
[[파일:Implicit Grant Type.png]] | |||
===리소스 소유자 암호 자격 증명=== | |||
[[파일:Resource Owner Password Credentials Grant.png]] | |||
===클라이언트 자격 증명=== | |||
[[파일:Client Credentials Grant Type.png]] | |||
==구성== | |||
{| class="wikitable" | |||
!구분 | |||
!설명 | |||
!비고 | |||
|- | |||
|자원 소유자 | |||
|요청하고자 하는 자원의 소유자이자, 인증 주체 | |||
|이용자 | |||
|- | |||
|클라이언트 | |||
|자원을 필요로 하는 서비스 | |||
자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청 | |||
|쇼핑몰 등 | |||
|- | |||
|권한 서버 | |||
|인증을 처리하고 권한을 부여하는 서버 | |||
| rowspan="2" |페이스북 | |||
네이버 | |||
구글 등 | |||
|- | |||
|자원 서버 | |||
|자원을 가지고 있는 서버 | |||
|- | |||
|접근 토큰 | |||
|자원 서버에 자원을 요청할 수 있는 토큰 | |||
|유효기간 존재 | |||
|- | |||
|재발급 토큰 | |||
|권한 서버에 접근 토큰을 요청할 수 있는 토큰 | |||
|접근 토큰 유효기간 만료 시 사용 | |||
|} | |||
==OAuth1.0과 OAuth2.0의 차이== | |||
{| class="wikitable" | |||
!비교 | |||
![[OAuth1.0]] | |||
![[OAuth2.0]] | |||
|- | |||
|참여자 구분 | |||
| | |||
*이용자 | |||
*소비자 | |||
*서비스 제공자 | |||
| | |||
*자원 소유자 | |||
*클라이언트 | |||
*권한 서버 | |||
*자원 서버 | |||
|- | |||
|토큰 | |||
| | |||
*요청 토큰(Request Token) | |||
*접근 토큰(Access Token) | |||
| | |||
*접근 토큰(Access Token) | |||
*재발급 토큰(Refresh Token) | |||
|- | |||
|유효기간 | |||
| | |||
*접근 토큰의 유효기간 없음 | |||
| | |||
*접근 토큰 유효기간 부여 | |||
*만료 시 재발급 토큰 이용 | |||
|- | |||
|클라이언트 | |||
| | |||
*웹 서비스 | |||
| | |||
*웹, 앱 등 | |||
|} | |||
==문제점== | |||
*OAuth를 제공하는 대형 플랫폼 서비스(신뢰된 서비스, 권한 서버, 자원 서버)에 개인의 행태 정보가 지나치게 축적되는 문제 | |||
**국가 기관이 아닌 신뢰된 서비스가 과연 신뢰할 수 있는가? | |||
==참고 문헌== | |||
*OAuth 2 IN ACTION(에이콘 출판사) |
Latest revision as of 09:41, 10 March 2022
- 자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜
- 애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한을 허용하고, 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근하는 프로토콜
역사[edit | edit source]
- 여러 웹 서비스를 연계하여 사용토록 하기 위해 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가지 타입으로 발표됨
관련 표준[edit | edit source]
- [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"]
구성과 종류[edit | edit source]
구성[edit | edit source]
- 리소스 소유자: API에 대한 권한을 가지고 있으며, 이를 위임할 수 있는 이용자
- 보호된 리소스: 리소스 소유자가 접근하는 대상
- 클라이언트: 리소스 소유자를 대신해 보호된 리소스에 접근하는 소프트웨어 등
- 인가 서버: 리소스에 접근할 수 있는 접근 토큰을 발급
프토토콜 종류[edit | edit source]
종류(Type) | 설명 |
---|---|
인가 코드 승인
(Authorization Code Grant) |
|
암묵적 승인
(Implicit Grant) |
|
리소스 소유자 암호 자격 승인
(Resource Owner Password Credentials Grant) |
|
클라이언트 자격 승인
(Client Credentials Grant) |
|
인증 절차[edit | edit source]
권한 부여 코드 승인[edit | edit source]
암시적 승인[edit | edit source]
리소스 소유자 암호 자격 증명[edit | edit source]
클라이언트 자격 증명[edit | edit source]
구성[edit | edit source]
구분 | 설명 | 비고 |
---|---|---|
자원 소유자 | 요청하고자 하는 자원의 소유자이자, 인증 주체 | 이용자 |
클라이언트 | 자원을 필요로 하는 서비스
자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청 |
쇼핑몰 등 |
권한 서버 | 인증을 처리하고 권한을 부여하는 서버 | 페이스북
네이버 구글 등 |
자원 서버 | 자원을 가지고 있는 서버 | |
접근 토큰 | 자원 서버에 자원을 요청할 수 있는 토큰 | 유효기간 존재 |
재발급 토큰 | 권한 서버에 접근 토큰을 요청할 수 있는 토큰 | 접근 토큰 유효기간 만료 시 사용 |
OAuth1.0과 OAuth2.0의 차이[edit | edit source]
비교 | OAuth1.0 | OAuth2.0 |
---|---|---|
참여자 구분 |
|
|
토큰 |
|
|
유효기간 |
|
|
클라이언트 |
|
|
문제점[edit | edit source]
- OAuth를 제공하는 대형 플랫폼 서비스(신뢰된 서비스, 권한 서버, 자원 서버)에 개인의 행태 정보가 지나치게 축적되는 문제
- 국가 기관이 아닌 신뢰된 서비스가 과연 신뢰할 수 있는가?
참고 문헌[edit | edit source]
- OAuth 2 IN ACTION(에이콘 출판사)