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