OAuth2

Tech Note 정보
카테고리: [ Miscellaneous ]
조회수: 16932

1. 개요

OAuth 2(2.0)는 인증을 위한 산업 표준 프로토콜이다. OAuth 2는 웹 응용 프로그램, 데스크톱 응용 프로그램, 휴대 전화 및 거실 장치에 대한 특정 권한 부여 흐름을 제공하면서 클라이언트 개발자의 단순성에 중점을 둔다. 이 사양 및 확장은 IETF OAuth Working Group 내에서 개발되고 있다.

그러면 토큰 기반의 보안 프레임워크인 OAuth2에 대해 알아본다.

2. OAuth2의 목표

사용자 요청을 처리하기 위해 여러 서비스를 호출할 때, 요청을 처리할 서비스에 하나하나 자격 증명을 제시하지 않고도 사용자를 인증하기 위한 것이다.

3. OAuth2의 구성요소

3.1. 보호자원

마이크로 서비스 등의 보호하려는 자원이다. 이는 적절한 권한을 부여받은 인증된 사용자만 접근 가능하다.

이 보호자원은 OAuth2 서버에 접속하여 토큰 유효성을 확인하고 사용자가 지정한 역할을 조회할 수 있다. 여기서 역할(role)이란 관련된 사용자를 그룹으로 묶고 이 그룹이 접근할 수 있는 자원을 정의한다.

3.2. 자원 소유자

자원 소유자가 등록한 애플리케이션은 서명 가능한 애플리케이션 이름과 secret key를 받는다. 애플리케이션 이름과 secret key는 OAuth2 토큰 인증 시 전달되는 자격 증명의 일부이다.

3.3. 애플리케이션

사용자를 대신하여 서비스를 호출할 애플리케이션이다. 다시 말해 사용자는 서비스를 직접 호출하지 않는다.

3.4. 인증서버

애플리케이션과 서비스 사이의 중개 역할을 수행한다. 

4. OAuth2 흐름

  1. 보호하려는 서비스, 즉 보호 자원이 있다.
  2. 자원 소유자는 OAuth2 서비스로 자원에 접근할 수 있는 애플리케이션과 사용자를 허가한다.
  3. 사용자가 보호 자원에 접근하려면 OAuth2 서비스에서 인증 후 토큰을 받아야 한다.
  4. OAuth2 서버는 사용자를 인증하고 전달된 토큰의 유효성을 확인한다. 

5. OAuth2 승인 방식의 종류

5.1. Autorization Code Grant Type (권한 부여 승인 타입) 

클라이언트가 다른 사용자 대신 특정 리소스에 접근 요청시 사용된다. 리소스 접근을 위한 사용자명, 비밀번호, 권한 코드를 사용하여 리소스에 대한 토큰을 얻는다.

  1. 클라이언트가 파라미터로 클라이언트 ID, 리다이렉트 URL, 응답 타입을 권한 서버에 전달한다. 정상적으로 인증이 되면 권한 부여 코드를 클라이언트에 보낸다. (응답 타입은 코드, 토큰 사용 가능. 토큰인 경우 암시적 승인에 해당)
  2. 클라이언트는 권한 부여 코드를 통해 억세스 토큰을 권한 서버에 추가로 요청한다. 이때는 클라이언트 ID, 클라이언트 비밀번호, 리다이렉트 URL, 인증 타입의 파라미터를 사용한다.
  3. 억세스 토큰을 받아 사용자 데이터를 리소스 서버에 보낸다.

5.2. Implicit Grannt Type (암시적 승인) 

Autorization Code Grant Type과 다르게 권한 코드 교환이 없다. 토큰을 즉시 받아 이를 인증에 이용한다.

5.3. Resource Owner Password Cedentials Grant Type (리소스 소유자 암호 자격 증명 타입) 

클라이언트가 암호를 사용하여 토큰에 대한 사용자 자격 증명을 교환한다.

5.4. Client Credentials Grant Type (클라이언트 자격 증명 타입)

클라이언트가 컨텍스트 외부에서 토큰을 얻어 리소스에 접근을 요청한다.

9. 마이크로 서비스 보안

마이크로 서비스 보안에서 OAuth2는 일부일뿐이다. 다음과 같은 추가적인 보안 고려가 필요하다.

  1. 모든 서비스 통신에 SSL(HTTPS)을 사용한다. 인터넷의 많은 예제들은 HTTP로 되어 있지만 실 환경에서는 HTTPS를 사용하는 것이 좋다. 아예 처음부터 HTTPS로 구성해야 나중에 두번 작업을 하지 않게 된다.
  2. 모든 서비스는 API Gateway를 통과한다. 즉 서비스별로 직접 접근할 수 없어야 한다. 각 마이크로 서비스는 Gateway를 통해 유입되는 요청만 처리해야 한다.
  3. 공개 API와 비공개 API를 분리한다. 예를 들어 공개 API는 OAuth2 인증을 수행하며, 워크플로 중심의 작업을 수행한다. 비공개 API는 비공개 네트워크 내에서 핵심 애플리케이션 및 데이터를 처리한다.
  4. 불필요한 네트워크 포트를 차단한다. 즉 최소한의 인바운드 요청만 허용한다.