OAuth: Difference between revisions

From IT Wiki
No edit summary
No edit summary
 
Line 15: Line 15:
*WRAP을 기반으로 OAuth 2.0 개발(RFC 6749, RFC 6750)
*WRAP을 기반으로 OAuth 2.0 개발(RFC 6749, RFC 6750)
*OAuth 2.0은 메커니즘이 하나로 통일되지 않아 4가지 타입으로 발표됨
*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"]


==구성과 종류==
==구성과 종류==
Line 139: Line 146:
==문제점==
==문제점==


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



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]

Authorization Code Grant Type.png

암시적 승인[edit | edit source]

Implicit Grant Type.png

리소스 소유자 암호 자격 증명[edit | edit source]

Resource Owner Password Credentials Grant.png

클라이언트 자격 증명[edit | edit source]

Client Credentials Grant Type.png

구성[edit | edit source]

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

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

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

네이버 구글 등

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

OAuth1.0과 OAuth2.0의 차이[edit | edit source]

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

문제점[edit | edit source]

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

참고 문헌[edit | edit source]

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