OAuth 1.0, OAuth 2.0

OAuth(Open Authorization)는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다 

 

OAuth의 탄생 이전에는 API 접근 위임 방식(API Access Delegation)이 가능한 표준화되지 않은 각각의 인증 방식을 제작하여 사용했다. OAtuh는 API 제어의 목적으로 인증에 참여한 각 이해관계자가 어떻게 서로를 신뢰할 수 있을까에서 시작하였다. 2006년 비밀번호의 통신 문제로 안전한 표준 인증방식에 대한 논의를 통해 2007년 OAuth 1.0이 만들어지고, 2010년에 IETF OAuth 워킹그룹에 의해 IETF 표준 프로토콜로 발표되었다. 현재는 OAuth의 세션 고정 공격을 보완한 OAuth 1.0 revision A 를 거쳐, OAuth의 구조적 문제점을 해결하고 핵심 요소만을 차용한 유사 프로토콜인 WRAP(Web Resource Access Protocol)을 기반으로 발표한 OAuth 2.0을 사용하고 있다. (현재 OAuth 2.0은 드래프트 단계)

 

OAuth를 통한 사용자 인증 과정을 두 명이 춤을 추듯 정확하게 정보를 주고받는 과정을 재미있게 표현하여 OAuth Dance라고 한다. 

 

1. OAuth 1.0

OAuth 1.0의 요소는 다음과 같다.

1) User: Service Provider에 계정을 보유하고, Consumer를 이용하려는 사용자

2) Service Provider: OAuth를 통한 데이터를 제공하는 서비스

3) Consumer: OAuth 인증을 사용하여 Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스

4) Request Token: Consumer가 Service Provider에게 접근 권한을 인증받기 위해 사용하는 값, 인증 완료 후에는 Access Token을 사용한다.

5) Access Token: 인증 완료 이후 자원에 접근하기 위한 키를 포함한 값

 

OAuth 1.0의 인증 과정은 다음과 같다.

1) Request Token 요청 및 발급

2) 사용자 인증 페이지 호출

3) 사용자 인증 및 로그인 완료

4) 사용자의 권한 요청 및 수락

5) Access Token 발급

6) Access Token을 이용한 서비스 정보 요청

 

OAuth 1.0에서 웹 애플리케이션 이외에는 인증 방식으로 사용하기 어려움이 있고, 절차가 복잡하여 이러한 단점을 개선하기 위해서 2.0이 등장한다. OAuth 2.0에서는 웹 애플리케이션 이외의 애플리케이션에 대한 지원을 강화하고, 별도의 암호화가 필요하지 않으며 HTTPS를 사용한다.(HMAC을 사용하지 않는다.) 또한, 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 하였으며, Signature 단순화 정렬과 URL 인코딩이 별도로 필요하지 않다.

 

2. OAuth 2.0

OAuth 2.0의 요소는 다음과 같다.

1) Resource Server: OAuth2.0을 활용한 서비스를 제공하고, 자원을 관리하는 서버

2) Resource Owner: Resource Server를 소유한 사용자

3) Client: Resoure Server의 데이터를 사용하려는 클라이언트

4) Authorization Server: Client가 Resource Server에 접근할 수 있도록 인증을 관리하는 서버 

5) Access Token: Resource Server에 자원을 요청할 수 있는 토큰

6) Refresh Token: Authorization Server에 접근 토큰을 요청할 수 있는 토큰 

 

OAuth 2.0은 다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따라 프로토콜을 4가지 방식으로 제공하고 있다.

1) Authorization Code Grant (권한 부여 승인 코드 방식)

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식 (가장 많이 사용되며 기본적)

2) Implicit Grant (암묵적 승인 방식)

자격증명을 안전하게 저장하기 힘든 클라이언트에게 최적회된 방식 (JavaScript 등의 스크립트 언어를 사용한 브라우저)

3) Resource Owner Password Credentials Grant (자원 소유자 자격증명 승인 방식)

자원 소유자의 자격증명을 통한 Access Token 발급 방식

4) Client Credentials Grant (클라이언트 자격증명 승인 방식)

클라이언트의 자격증명으로 Access Token 발급 방식

 

Authorization Code Grant 방식의 OAuth 2.0의 인증 과정은 다음과 같다.

1) 사용자가 Client의 서비스에 접근한다.

2) Client는 사용자에게 접근권한을 요청한다. 

3) Client는 사용자를 서비스 제공자와 연결한다. 

4) 서비스 제공자는 사용자에게 Client가 리소스에 접근하기 위한 권한 허용여부를 질의한다.

5) 사용자가 허락했을 경우 서비스 제공자는 Client에게 Access Token 발급을 위한 인가 코드를 전달한다.

6) Client는 인가 코드를 통해 Access Token을 요청한다.

7) Client는 Access Token을 활용하여 필요한 리소스를 요청한다. 

8) Resource Server는 Access Token을 확인 후 Client에게 리소스를 전달한다. 

9) Client는 전달받은 리소스를 활용하여 사용자에게 서비스를 제공한다.

 

 

# 참고자료

https://www.rfc-editor.org/rfc/rfc6749

https://d2.naver.com/helloworld/24942

https://blog.naver.com/mds_datasecurity/222182943542

https://oauth.net/