OAuth(2) - 역할 및 유형

OAuth 역할들(Roles)

OAuth에서 위임 방식의 인가를 처리하기 위해 4 개의 역할들을 정의하고 있으며 이들은 아래 표와 같습니다.

 

---

인가 승인 유형(Authorization Grant Types)

클라이언트가 접근 토큰을 요청하기 위해서는 자원 소유자의 인가를 받아야 하는데 OAuth는 서로 다른 용도를 위해 다양한 인가 승인 유형을 제공합니다. OAuth에서 정의한 4가지 인가 승인 유형은 아래와 같습니다.

 

 

(1) 인가 코드 승인(Authorization Code Grant)

인가 코드 승인 방식은 HTTP 리다이렉션 기반 흐름이어서 클라이언트는 자원 소유자의 웹 브라우저와 상호작용할 수 있어야 하며 인가 서버로부터의 요청을 처리할 수 있어야 합니다. 승인 흐름은 아래 그림과 같습니다.

 

1. 클라이언트가 사용자 에이전트를 인가 서버로 리다이렉트 함으로써 흐름을 시작합니다. (상태(State) 값과 인가 서버로부터 응답을 수신할 Redirect URI 포함)
2. 유효한 인증 이력이 없는 인증 요청에 대해 인가 서버는 로그인 페이지로 응답합니다.
3. 자원 소유자는 인가 서버의 인증을 통해 클라이언트를 인가합니다.
4. 인가 서버는 정상적인 자원 소유자의 인증/인가 요청을 클라이언트로 리다이렉트 합니다. (인가 코드, 상태 값 포함)
5. 인가 코드를 포함한 요청을 받은 클라이언트는 인가 서버로 접근 토큰 요청을 전송하여 그 결과로 접근 토큰을 획득합니다. (인가 코드, 클라이언트 인증 정보 포함)

이 방식은 위 그림에서 볼 수 있듯이 클라이언트의 인증 과정을 거치고 인가 서버와 클라이언트 간에만 접근 토큰이 포함된 통신을 수행하는 등 보안 상 많은 이점을 포함하고 있습니다.

 

 

(2) 암시적 승인(Implicit Grant)

암시적 승인은 브라우저에서 자바스크립트와 같은 스크립트 언어로 동작하는 클라이언트들을 지원하기 위한 승인 유형입니다. 웹 브라우저의 신뢰도가 높고, 신뢰할 수 없는 사용자나 애플리케이션에 노출될 염려가 적을 때 사용합니다. 모바일 앱 또는 단말기에서 동작하는 웹 애플리케이션에서 주로 사용됩니다. 승인 흐름은 아래 그림과 같습니다.

 

1. 클라이언트가 사용자 에이전트를 인가 서버로 리다이렉트 함으로써 흐름을 시작합니다. (상태(State) 값과 인가 서버로부터 응답을 수신할 Redirect URI 포함)
2. 유효한 인증 이력이 없는 인증 요청에 대해 인가 서버는 로그인 페이지로 응답합니다.
3. 자원 소유자는 인가 서버의 인증을 통해 클라이언트를 인가합니다.
4. 인가 서버는 정상적인 자원 소유자의 인증/인가 요청에 접근 토큰으로 응답합니다.
5. 클라이언트는 접근 토큰을 획득합니다.

이 방식은 재발급 토큰을 사용할 수 없기 때문에 접근 토큰이 만료되면 클라이언트는 접근이 필요한 경우 승인 흐름을 다시 진행해야 합니다.

 

 

(3) 자원 소유자 패스워드 승인(Resource Owner Password Grant)

자원 소유자 패스워드 승인은 사용자 이름과 비밀번호를 접근 토큰으로 교환합니다. 승인 흐름은 아래 그림과 같습니다.

1. 클라이언트는 사용자에게 사용자 인증 정보를 요청합니다.
2. 입력 받은 사용자 인증 정보와 클라이언트 정보를 포함하여 인가 서버로 접근 토큰 요청을 보냅니다.
3. 인가 서버는 정상적인 자원 소유자의 인증/인가 요청에 대해 접근 토큰으로 응답합니다.

자원 소유자의 비밀번호가 클라이언트에 노출되기 때문에 다른 유형의 승인 방식을 사용할 수 없는 경우에만 사용해야 합니다.

 

(4) 클라이언트 인증 정보 승인(Client Credentials Grant)

클라이언트 인증 정보 승인은 클라이언트가 데이터를 소유하고 있어서 자원 소유자에게 접근을 위임 받을 필요가 없거나, 외부에서 애플리케이션에 접근 위임이 이미 허용되었을 경우에 사용합니다. 사용자와 관계없는 애플리케이션 API 접근 시에 주로 사용됩니다. 승인 흐름은 아래 그림과 같습니다.

1. 클라이언트는 클라이언트 인증 정보를 담은 요청을 인가 서버로 보냅니다.
2. 인가 서버는 정상적인 클라이언트 인증/인가 요청에 대해 접근 토큰으로 응답합니다.

이 방식은 정확한 사용 사례에 따라 사용되어야 합니다. 고도의 비밀 유지가 필요한 클라이언트를 인증하는 것은 매우 위험하므로, 이런 경우에는 인증 정보를 규칙적으로 바꿔줘야 합니다.

 

 

 

 

 

---

클라이언트 유형 

 

(1) 안전성 

클라이언트는 자격증명을 안전하게 보관 및 관리할  수 있는지 여부에 따라 크게 비밀(Confidentiality) 및 공개(Public)

 

 

(2) 구축 방식

클라이언트는 구축 방식에 따라 웹 애플리케이션(Web application),  이용자 에이전트 애플리케이션(User-agent-based application), 네이티브  애플리케이션(Native application)으로 분류

 

 

---

클라이언트 등록 

OAuth 2.0에서는 API 요청을 한 클라이언트를 식별 및 검증하기 위해, 먼저 권한 서버에 클라이언트를 등록하도록 정의
  - 일반적으로 권한 서버(또는 API 개발자 사이트)에서 제공하는 HTML  양식을 통해 개발자(사)가 직접 등록함
  - 등록이 완료되면, 권한 서버는 클라이언트 자격증명 정보 중 하나인  client_id, client_secret*를 발급하며,

    클라이언트 개발자는 이 자격증명을  애플리케이션 개발 시 포함시킴 

  - 접근 토큰 요청 및 오픈 API 호출 시 등록된 정상 클라이언트인지 검증하는데 사용됨