OAuth2.0 - RFC6749 정리 (1)

1. 소개

 

OAuth2.0 도입 전의 클라이언트/서버 구현은 일단 Resource에 접근하기 위해서 Resource Server를 통해서

사용자 인증을 거친 후, 인증이 성공되면 이 후 Resource 접근 가능한 구조였다.

각 사용자별로 Resource 접근 시마다 인증 성공 여부를 Check해야 한다. 

OAuth2.0을 도입 시, 어떤 장점이 있고, 단점은 무엇인지 아래 글을 통해서 느껴본다.

 

1.1. 전통적인 모델의 문제점

• 클라이언트(third-party app.)가 향 후 리소스 재 접근을 위하여 리소스 소유자의 Credential을 저장해야 함.
  • OAuth2.0 : Credential 사용 대신, Access Token을 사용
• 패스워드 인증 방식은 보안에 취약한 부분이 존재, 서버가 이 방식만을 인증 방식으로 사용해야하는 제약
  • OAuth2.0 : code, implict grant type은 클라이언트 등록 절차와 리소스 소유자 인증 절차로 보안강화
• 클라이언트가 광범위한 접근 권한을 획득 (사용자별 또는 리소스별 다른 권한 설정이 어려움)
  • OAuth2.0 : OAuth2.0 Access Token의 scope 구문을 사용하여 제어 가능
• 리소스 소유자의 클라이언트의 권한 회수가 어렵다
  • 리소스 소유자는 언제든지 필요 시, 권한 회수가 가능하다.
• Third-party App.의 보안상 허점으로 리소스 소유자의 PW와 PW로 보호된 모든 데이터가 노출될 수 있다.
  • OAuth2.0 : code, access token 및 refresh token이 노출될 수 있다.
  • OAuth2.0에서 발행한 데이터는 유효 기간이라 노출 시간이 제한적이다. 예) access token의 expires_in

2. OAuth2.0 구성요소 (Role)

1. Resource Owner
   • 리소스의 실제 소유자 또는 리소스 접근을 허용할 수 있는 권한을 가진자 (사람인 경우 end-user라 명명)
2. Resource Server
   • 리소스를 관리 서버
3. Client
   • 리소스 소유자를 대리하여 리소스 접근을 요청하는 자(보통 Third-Party App.)
4. Authorization Server
   • 주 역활은 Access Token 발행 서버
   • Refresh Token 발행 
   • Client 인증 (Authorization Grant Type이 Code 일 경우)

Client와 Resource Owner에 대한 개념은 잘 와 닿지 않지만, RFC문서를 반복해 읽다가 보면 어느정도 개념은 잡을 수 있다. 

 

3. Abstract OAuth2.0 Flow

 

그림 1. https://www.websequencediagrams.com/#open=517071

 

(A) Client는 Resource Owner에게 직접 또는 Authorization Server를 통한 간접 방식으로 Authorization을 요청

(B) Authorization Grant를 Resource Owner로부터 받는다. Grant Type의 종류는 크게 4가지로 다음절에서 상세 기술한다.

Client가 요청하거나 Server가 지원하는 Type에 따라 결정된다.

나머지 부분은 이해에 큰 무리가 없어서 생략

 

참고 : (B)와 (C)는 Authorization Grant Type에 따라 수행 여부가 존재하지 않을 수 있다.

 

4. Authorization Grant Types

 

Authorizaton Code, Implicit, Resoure Owner Password Credentials 및 Client Credentials가 있다.

 

4.1. Authorization Code

 

그림 2. https://www.websequencediagrams.com/#open=517090

그림 1.을 Authorization Grant Type이 Authorization Code 관점으로 확장에서 그리면 그림 2.와 같다.

먼저 Authorization Server로부터 Authorization Code를 발급 받아야 한다. 이는 Client에게

Access Token을 발급 받을 수 있는 자격을 주는 것으로 이해하면된다.

Authorization Code를 발급 받기 위해서는 Authorization Server가 결국 Resource Owner (User)를

인증할 수 밖에 없다. Authorization Code를 발급 받은 Client은 이제 Authorization Server로부터

Access Token을 발급 받을 수 있다. 이 때 이 Code를 통해서 Client를 인증하는 것이다.

 

결국 Authorization Server입장에서는 Resource Owner(User)와 Client 인증을 두가지를 수행하고 있다.

이는 Client Type이 Credential일 경우에 이 방식을 채용한다.

 

4.2. Implicit

 

그림 3. https://www.websequencediagrams.com/#open=517456

 

Implicit 방식은 Client 인증이 존재하지 않는다. 따라서 Authorization Code Grant Type에서 Code를 발급받는 과정이 없다.

대신 Client의 인증은 Client 등록 과정에서 제공한 Redirection URL을 비교해서 등록했을 때 값과 비교하여 동일하면

Client 인증은 완료된다.

Client가 Access Token을 발급 받기 위해서는 Resource Owner의 인증과정은 필요하다.

따라서 이 방식은 Resource Owner (User) 인증만 존재한다.

 

4.3. Resource Owner Password Credentials

 

그림 4. https://www.websequencediagrams.com/#open=517458

Resource Owner Password Credentials 방식은 Client가 Resource Owner에게서 받은 Credential 정보를

Authorization Server에 전달함으로써 Access Token을 발급 받는다.

Resource Owner가 Client에게 자신의 Credential을 전달하는 과정은 표준에서 다루지 않고 구현의 몫이다.

 

4.4. Client Credentials

 

그림 5. https://www.websequencediagrams.com/#open=517459

Authorization Request 정보로 Client 자기 자신의 Credential을 사용하고 있다. Authorization Scope가 Client 자신에 해당하는 Resource에 한정되어 있을 경우만 사용한다. 또한 Client와 Resource Owner가 같은 경우에 주로 사용한다.

 

5. Access Token & Refresh Token

 

Access Token은 기본적으로 Scope과 Duration 속성을 가지고 있고, 정확한 포멧과 구조는 Security 요구 사항에 따라 구현단의 선택 몫이다. Duration은 10분 정도로 설정해서 사용하기를 권고하고 있다.

Refresh Token은 필수는 아니고 선택항목이다. Access Token을 재 발급 받기 위해서 사용되는 것으로 이 또한 Scope와 Duration 속성을 가지고 있다. Security 요구사항과 구현에 따라 구현단의 몫이다.

 

여기까지 추상적인 관점에서 전체 구성요소와 흐름을 알아 보았다. 이어지는 페이지에서는 좀 더 구체적으로 알아보도록 한다. 아래 그림은 전체 흐름에 대한 그림이다.

 

그림 6. https://www.websequencediagrams.com/#open=517467