OAuth2

API를 통해 특정 시스템의 보호된 자원에 접근하기 위해서는 해당 시스템의 사용자 인증 정보(아이디, 패스워드)를 알고 있어야 합니다. 시스템 차원에서 다른 시스템의 보호된 자원에 접근하기 위해 그 시스템의 사용자 인증 정보를 관리하고 이 정보를 사용하는 것은 보안상 많은 문제들을 유발할 수 있습니다. 이런 문제들이 발생하지 않도록 API 접근을 위임하여 인증을 처리하는 방법을 사용할 수 있습니다.

많은 서비스 제공자(Google, Yahoo, AOL 등)들이 이런 인증 방식을 별도로 구현하여 사용하였습니다. 이렇게 구현된 결과들은 서로 조금씩 다르고 서로 호환되지 않았는데 이를 통일하기 위해 OAuth 1.0 표준안을 만들었습니다.

OAuth 1.0 발표 이후 몇 년 동안 사용하면서 커뮤니티는 아래와 같은 단점들에 대해 고민하였고 그 결과 OAuth 2(이후 ‘OAuth’로 명명)를 표준으로 정리하였습니다.

• 암호화 요구사항의 복잡성
• 웹 기반 애플리케이션만 지원
• 성능 확장에 어려움

 

1. OAuth 역할들(Roles)

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

역할설명

자원 서버 (Resource Server)	자원 서버는 보호된 정보를 제공하는 서버로 일반적으로 웹 애플리케이션입니다.
자원 소유자 (Resource Owner)	자원 소유자는 자원 서버에 계정을 가지고 있는 사용자로 클라이언트가 그들의 계정을 통해 자원 서버에 접근하는 것을 인가(authorize)합니다.
클라이언트 (Client)	클라이언트는 자원 소유자를 대신하여 자원 서버의 서비스를 사용하고자 하는 애플리케이션입니다.
인가 서버 (Authorization Server)	인가 서버는 클라이언트가 자원 서버의 서비스를 사용할 때 사용하는 접근 토큰(Access Token)을 발행합니다.

2. 인가 승인 유형(Authorization Grant Types)

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

인가 승인 유형용도비고

인가 코드 승인 (Authorization Code)	웹 서버 상에서 동작하는 애플리케이션	가장 많이 사용되는 유형
암시적 승인 (Implicit)	모바일 앱 또는 단말기에서 동작하는 웹 애플리케이션
자원 소유자 패스워드 승인 (Resource Owner Password)	단말기 OS 또는 높은 신뢰 관계의 애플리케이션	다른 유형들을 사용할 수 없는 경우에만 사용
클라이언트 인증 정보 승인 (Client Credentials)	애플리케이션 API 접근	신뢰하는 클라이언트만 사용

2.1. 인가 코드 승인(Authorization Code Grant)

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

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

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

3. 로그인 시나리오

1. SSO 구성 환경에서 SSO 처리 시나리오는 아래 그림과 같습니다.

   한 시스템을 통해 로그인한 사용자가 다른 시스템의 인증이 요구되는 페이지를 요청하면 해당 시스템은 이 요청을 SSO 서버로 리다이렉트 합니다.
   1. 유효한 인증 이력이 있는 요청에 대해 SSO 서버는 이 요청을 시스템으로 리다이렉트 (인가 코드 포함)합니다.
   2. 인가 코드를 포함한 요청을 받은 시스템은 SSO 서버로부터 접근 토큰과 사용자 정보를 획득하여 해당 사용자의 로그인 처리를 한 후 원래 요청의 결과로 응답합니다.

 

4. 로그아웃 시나리오

로그인한 사용자가 SSO 환경에서 로그아웃 시 처리 과정은 아래 그림과 같습니다.

1. 로그인한 사용자가 한 시스템에게 로그아웃을 요청하면 시스템은 이 요청을 SSO 서버의 로그아웃 페이지로 리다이렉트 합니다.
2. 로그아웃 요청을 받은 SSO 서버는 해당 사용자로 로그인된 모든 시스템에게 로그아웃을 요청합니다.

샘플 소스 코드

https://github.com/Sangjun1/spring-boot-oauth2-example