[Spring Security] OAuth2란?

OAuth2란?

서비스를 제공하는 애플리케이션에서 해당 서비스를 이용하는 사용자의 크리덴셜(Credential)을 직접적으로 관리하는 것이 전통적인 방법이다.

 

만약 서버가 사용자의 크리덴셜을 관리하는 환경에서 Google Calender API를 이용한다고 가정한다면, 해당 서비스는 회원 가입을 통해 사용자의 크리덴셜을 관리해야 함은 물론이고 Google Calender API를 이용하기 위해 Google에서 사용하는 사용자의 크리덴셜까지 관리해야 한다.

 

이런 상황에서의 문제점은 사용자에게 중요한 정보인 크리덴셜이 두 개로 생성되어 관리됨으로써 보안상의 문제와, Google에서 패스워드를 변경한다고 가정한다면 해당 서비스 애플리케이션에서도 업데이트해주어야 한다는 것이다.

 

이런 문제점을 보완하는 효과적인 방법 중 하나가 OAuth2 인증 프로토콜을 사용하는 것이다.

OAuth2는 특정 애플리케이션에서 사용자의 인증을 직접 처리하는 것이 아니라 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션(GitHub, Google, Facebook 등)에서 사용자의 인증을 대신 처리해 주고 Resource에 대한 자격 증명용 토큰을 발급한 후, Client가 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식이다.

---

OAuth2를 사용하는 애플리케이션 유형

1. 써드 파티 애플리케이션에서 제공하는 API의 직접적인 사용

• Google, Github, Facebook과 같은 신뢰할만한 써드 파티 애플리케이션에서 제공하는 API를 직접적으로 사용할 경우

2. 추가적인 인증 서비스 제공 용도

• 일반적으로 제공하는 아이디/패스워드 로그인 인증 외에 OAuth2를 이용한 로그인 인증 방법을 제공할 경우
• 애플리케이션에서 사용자의 크리덴셜을 남기고 싶지 않을 경우

---

OAuth2의 동작 방식

1. OAuth2 인증 컴포넌트들의 역할

Resource Owner

• 사용하고자 하는 Resource의 소유자를 말한다. (Google 등의 서비스를 이용하는 사용자)

Client

• Resource Owner를 대신해 보호된 Resource에 액세스하는 애플리케이션이다. (API를 이용하는 애플리케이션)

Resource Server

• Client의 요청을 수락하고 Resource Owner에게 해당하는 Resource를 제공하는 서버이다. (API를 제공하는 Google 등의 서비스)

Authorization Server

• Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버이다.
• Resource Owner가 인증에 성공하면 Client에게 Access Token 형태로 Resource에 접근할 수 있는 권한을 준다.

 

2. OAuth2 인증 컴포넌트 간의 인증 처리 흐름

1. Resource Owner는 Client에게 OAuth2 인증을 요청한다.
2. Client는 Resource Owner가 자신의 계정 정보를 관리하고 있는 써드 파티 애플리케이션에 로그인할 수 있도록 해당 로그인 페이지로 리다이렉트(Redirect)한다.
3. 써드 파티 애플리케이션의 로그인 페이지에서 Resource Owner가 로그인 인증을 진행하고 성공한다.
4. Authorization Server가 Resource Owner의 로그인 인증을 성공했음을 증명하는 Access Token을 Client에게 전송한다.
5. Access Token을 전달 받은 Client는 Resource Server에게 Resource Owner 소유의 Resource를 요청한다.
6. Resource Server는 Client가 전송한 Access Token을 검증 후에 Resource를 Client에게 전송한다.

---

OAuth2 인증 프로토콜에서 사용되는 용어

Authorization Grant

• Client가 Access Token을 얻기 위한 Resource Owner의 권한을 표현하는 크리덴셜을 의미한다.
• Authorization Grant의 네 가지 타입
  • Authorization Code
  • Implicait Grant Type
  • Client Credentials
  • Resource Owner Password Credentials

Access Token

• Client가 Resource Server에 있는 보호된 Resource에 액세스하기 위한 자격 증명용 토큰이다.
• Authorization Code와 Client Secret을 이용해 Authorization Server로 부터 전달 받은 Access Token으로 자격 증명을 하면 Resource Server에 접근할 수 있는 것이다.

Scope

• 주어진 Access Token을 사용하여 액세스할 수 있는 Resource 범위를 의미한다.

---

Authorization Grant 유형

1. Authorization Code Grant : 권한 부여 승인 코드 방식

• 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로, 많이 쓰이고 기본이 되는 방식이다.
• Refresh Token을 사용할 수 있다.
• 권한 부여 승인 요청 시, 응답 타입(response_type)을 code로 지정하여 요청한다.

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

인증 처리 흐름

1. Resource Owner가 Client에게 서비스 요청을 보낸다.
2. Client는 Authorization Server에게 Authorization Code 요청과 동시에 Client ID, Redirect URI, 응답 타입을 함께 전송한다.
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행한다.
4. Authorization Server는 로그인이 확인되면 전달받은 Redirect URI로 Client에게 Authorization Code를 전달한다.
5. Client는 Authorization Server에게 Access Token 요청과 동시에 전달 받은 Authorization Code와 Client Secret, Redirect URI, 권한 부여 방식을 함께 전송한다.
6. Authorization Server는 요청 정보 확인 후, Redirect URI로 Client에게 Access Token을 발급해준다.
7. Client는 발급 받은 Access Token을 이용해 Resource Server에게 Resource를 요청한다.
8. Resource Server는 Access Token을 확인한 후, 요청 받은 Resource를 Client에게 전달한다.

 

2. Implicit Grant : 암묵적 승인 방식

• 별도의 Authorization Code 없이 바로 Access Token을 발급하는 방식이다.
• 자격 증명을 안전하게 저장하기 힘든 Client에게 최적화된 방식이다.
• Refresh Token 사용이 불가능하다.
• Authorization Server는 Client Secret을 통해 클라이언트 인증 과정을 생략한다.
• 권한 부여 요청 시, 응답 타입(response_type)을 token으로 지정하여 요청한다.

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

인증 처리 흐름

1. Resource Owner가 Client에게 서비스 요청을 보낸다.
2. Client는 Authorization Server에게 접근 권한 요청과 동시에 Client ID, Redirect URI, 응답 타입을 함께 전송한다.
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행한다.
4. Authorization Server는 로그인이 확인되면 전달 받은 Redirect URI로 Client에게 Access Token을 전달한다.
5. Client는 발급 받은 Access Token을 이용해 Resource Server에게 Resource를 요청한다.
6. Resource Server는 Access Token을 확인한 후, 요청 받은 Resource를 전달한다.

 

3. Resource Owner Password Credential Grant : 자원 소유자 자격 증명 승인 방식

• 간단하게 username, password로 Access Token을 발급받는 방식이다.
• 자신의 서비스에서 제공하는 애플리케이션의 경우에만 사용되는 인증 방식이다.
• Refresh Token 사용이 가능하다.
• Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해 있을 때만 사용 가능하다.
• 예로, 카카오 계정으로 카카오 지도 애플리케이션에 로그인하는 경우

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

인증 처리 흐름

1. Resource Owner가 Client에게 서비스 요청을 보낸다.
2. Client는 Authorization Server에게 Acceess Token 요청과 동시에 Client ID, 권한 부여 방식, 로그인 정보(username, password)를 함께 전달 한다.
3. Authorization Server는 요청과 함께 온 정보들을 확인한 후 Client에게 Access Token을 전달한다.
4. Client는 발급받은 Access Token을 이용해 Resource Server에게 Resource를 요청한다.
5. Resource Server는 Access Token을 확인한 후, 요청 받은 Resource를 전달한다.

 

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

• Client 자신이 관리하는 Resource 혹은 Authorization Server에 해당 Client를 위한 제한된 Resource 접근 권한이 설정되어 있는 경우 사용 가능한 방식이다.
• 이 방식은 자격 증명을 안전하게 보관할 수 있는 Client에서만 사용되어야 한다.
• Refresh Token 사용이 불가능하다.