OAuth

자신이 소유한 리소스에 소프트웨어 애플리케이션이 접근할 수 있도록 허용해 줌으로써 접근 권한을 위임해주는 개방형 표준 프로토콜

• 애플리케이션이 리소스 소유자에게 리소스에 대한 접근 권한을 허용하고, 요청 결과로 전달받은 토큰을 이용해 애플리케이션이 해당 리소스에 접근하는 프로토콜

1 역사

• 여러 웹 서비스를 연계하여 사용토록 하기 위해 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가지 타입으로 발표됨

2 구성과 종류

2.1 구성

• 리소스 소유자: API에 대한 권한을 가지고 있으며, 이를 위임할 수 있는 이용자
• 보호된 리소스: 리소스 소유자가 접근하는 대상
• 클라이언트: 리소스 소유자를 대신해 보호된 리소스에 접근하는 소프트웨어 등
• 인가 서버: 리소스에 접근할 수 있는 접근 토큰을 발급

3 프토토콜 종류

종류	설명
권한 부여 코드 승인 (Authorization Code Grant Type)	클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용 리스소 접근을 위한 사용자 명과 비밀번호, 권한 서버에 요청해서 받은 권한 코드를 함께 활용하여 리소스에 대한 엑세스 토큰을 받는 방식
암시적 승인 (Implicit Grant Type)	권한 부여 코드 승인 타입과 다르게 권한 코드 교환 단계 없이 엑세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식
리소스 소유자 암호 자격 증명 (Resource Owner Password Credentials Grant Type)	클라이언트가 암호를 사용하여 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식
클라이언트 자격 증명 (Client Credentials Grant Type)	클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식

4 인증 절차

4.1 권한 부여 코드 승인

4.2 암시적 승인

4.3 리소스 소유자 암호 자격 증명

4.4 클라이언트 자격 증명

5 구성

구분	설명	비고
자원 소유자	요청하고자 하는 자원의 소유자이자, 인증 주체	이용자
클라이언트	자원을 필요로 하는 서비스 자원 소유자의 권한으로 권한 서버에서 인증을 받아 자원 서버에 자원 요청	쇼핑몰 등
권한 서버	인증을 처리하고 권한을 부여하는 서버	페이스북 네이버 구글 등
자원 서버	자원을 가지고 있는 서버
접근 토큰	자원 서버에 자원을 요청할 수 있는 토큰	유효기간 존재
재발급 토큰	권한 서버에 접근 토큰을 요청할 수 있는 토큰	접근 토큰 유효기간 만료 시 사용

6 OAuth1.0과 OAuth2.0의 차이

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

7 문제점

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

8 참고 문헌

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