OAuth: 두 판 사이의 차이

IT위키
편집 요약 없음
편집 요약 없음
 
(사용자 3명의 중간 판 5개는 보이지 않습니다)
1번째 줄: 1번째 줄:
[[분류:보안]]
[[분류:보안]]
;제3의 신뢰 서비스에서 인증 결과를 토큰 기반으로 공유받아 활용하는 개방형 표준 프로토콜


== 인증 절차 ==
;자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜
* OAuth2.0의 프토코톨은 3가지 종류가 있음
 
** Implicit Grant
*애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한을 허용하고, 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근하는 프로토콜
** Resource Owner Password Credentials Grant
 
** Client Credentials Grant Type
==역사==
* 아래는 이해가 쉬운 Resource Owner Password Credentials Grant 방식의 인증 절차
 
*여러 웹 서비스를 연계하여 사용토록 하기 위해 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]]
[[파일:Resource Owner Password Credentials Grant.png]]


== 구성 ==
===클라이언트 자격 증명===
[[파일:Client Credentials Grant Type.png]]
 
==구성==
{| class="wikitable"
{| class="wikitable"
! 구분
!구분
! 설명
!설명
! 비고
!비고
|-
|-
| 자원 소유자
|자원 소유자
| 요청하고자 하는 자원의 소유자이자, 인증 주체
|요청하고자 하는 자원의 소유자이자, 인증 주체
| 이용자
|이용자
|-
|-
| 클라이언트
|클라이언트
| 자원을 필요로 하는 서비스
|자원을 필요로 하는 서비스
자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청
자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청
| 쇼핑몰 등
|쇼핑몰 등
|-
|-
| 권한 서버
|권한 서버
| 인증을 처리하고 권한을 부여하는 서버
|인증을 처리하고 권한을 부여하는 서버
| rowspan="2" | 페이스북
| 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(에이콘 출판사)

2022년 3월 10일 (목) 09:41 기준 최신판


자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜
  • 애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한을 허용하고, 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근하는 프로토콜

역사[편집 | 원본 편집]

  • 여러 웹 서비스를 연계하여 사용토록 하기 위해 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)

  • 클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식

인증 절차[편집 | 원본 편집]

권한 부여 코드 승인[편집 | 원본 편집]

Authorization Code Grant Type.png

암시적 승인[편집 | 원본 편집]

Implicit Grant Type.png

리소스 소유자 암호 자격 증명[편집 | 원본 편집]

Resource Owner Password Credentials Grant.png

클라이언트 자격 증명[편집 | 원본 편집]

Client Credentials Grant Type.png

구성[편집 | 원본 편집]

구분 설명 비고
자원 소유자 요청하고자 하는 자원의 소유자이자, 인증 주체 이용자
클라이언트 자원을 필요로 하는 서비스

자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청

쇼핑몰 등
권한 서버 인증을 처리하고 권한을 부여하는 서버 페이스북

네이버 구글 등

자원 서버 자원을 가지고 있는 서버
접근 토큰 자원 서버에 자원을 요청할 수 있는 토큰 유효기간 존재
재발급 토큰 권한 서버에 접근 토큰을 요청할 수 있는 토큰 접근 토큰 유효기간 만료 시 사용

OAuth1.0과 OAuth2.0의 차이[편집 | 원본 편집]

비교 OAuth1.0 OAuth2.0
참여자 구분
  • 이용자
  • 소비자
  • 서비스 제공자
  • 자원 소유자
  • 클라이언트
  • 권한 서버
  • 자원 서버
토큰
  • 요청 토큰(Request Token)
  • 접근 토큰(Access Token)
  • 접근 토큰(Access Token)
  • 재발급 토큰(Refresh Token)
유효기간
  • 접근 토큰의 유효기간 없음
  • 접근 토큰 유효기간 부여
  • 만료 시 재발급 토큰 이용
클라이언트
  • 웹 서비스
  • 웹, 앱 등

문제점[편집 | 원본 편집]

  • OAuth를 제공하는 대형 플랫폼 서비스(신뢰된 서비스, 권한 서버, 자원 서버)에 개인의 행태 정보가 지나치게 축적되는 문제
    • 국가 기관이 아닌 신뢰된 서비스가 과연 신뢰할 수 있는가?

참고 문헌[편집 | 원본 편집]

  • OAuth 2 IN ACTION(에이콘 출판사)