Spring Security (스프링 시큐리티) OAuth2 정리
현재 개발중인 프로젝트에서 여러 소셜 로그인을 사용할 예정이므로 OAuth 2.0 에 대해 학습 및 구현에 대해 정리하고자 한다.
OAuth 2.0 란?
구글, 네이버 등 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제 3자 클라이언트(우리가 출시한 웹 또는 앱 서비스)가 사용자의 권한을 위임 받을 수 있는 표준 프로토콜이다.
예를 들어, 우리가 웹서비스를 출시했다고 할 때 우리의 웹을 이용하는 사용자의 타사 플랫폼 정보에 접근하기 위한 권한을 타사 플랫폼으로부터 위임받는 것이다.
OAuth 2.0 특징
- 인증을 위한 개방현 표준 프로토콜이다.
- '제 3자 애플리케이션'이 사용자를 대신해 HTTP 서비스를 이용할 수 있는 권한을 부여하는 메커니즘을 제공한다.
- 구글, 카카오, 네이버 등에서 제공하는 간편 로그인 기능도 OAuth2 프로토콜 기반의 사용자 인증 기능이다.
OAuth 2.0 주체
| Resource Owner | 우리의 서비스를 이용하면서, 구글과 같은 플랫폼에서 리소스를 소유하고 있는 사용자이다. |
| Authorization | Resource Owner을 인증하고, Client에게 액세스 토큰을 발급해주는 서버이다. |
| Resource Server | 구글, 네이버와 같이 리소스를 가지고 있는 서버를 말한다. |
| Client | Resource Server의 자원을 이용하고자 하는 서비스 (ex.우리가 개발하려는 서비스) |
OAuth 2.0 주요 용어
| Authentication (인증) | Resource Owner이 자신임을 증명하는 과정을 의미한다. |
| Authorization (인가) | 인가, 자원에 접근할 권한을 부여하는 것이다. 인가가 완료되면 리소스 접근 권한이 담긴 Access Token이 클라이언트에게 부여된다. |
| Access Token | Resource Server로부터 Resource Owner의 보호된 자원을 획득할 때 사용되는 Token 이다. Access Token은 일정 기간 후 만료되므로, 기간이 만료되면 Refresh Token을 사용하여 새 토큰을 발급받아야 한다. |
| Refresh Token | Access Token 만료 시 이를 갱신하기 위한 용도로 사용하는 Token이다. |
OAuth 2.0 권한 부여 방식
Authorization Code Grant (권한 부여 승인 코드 방식)
- 보편적으로 웹 애플리케이션에서 사용되는 가장 일반적인 OAuth 2.0 인증방식이다.
- 이 방식은 리다이렉션을 통해 사용자의 인증과 인가를 처리하며, 사용자가 신뢰할 수 있는 인증 서버에서 인증을 받게 된다.
주요단계
1. 사용자 인증 요청
클라이언트 애플리케이션이 사용자를 인증 서버로 리다이렉트한다. 이 리다이렉트 요청은 클라이언트 애플리케이션의 식별자, 요청하는 접근 범위, 리다이렉트 URI, 상태정보를 포함하며 이를 통해 인증 서버는 클라이언트 애플리케이션을 식별하고 인증 과정을 진행한다.
2. 사용자 인증
인증 서버에서 사용자에게 로그인 페이지를 제공하여 사용자의 자격증명을 받는다.
이 정보는 클라이언트 애플리케이션에 전달되지 않는다.
3. 사용자 인가
인증이 성공하면 인증 서버는 사용자에게 클라이언트 애플리케이션이 요청하는 접근 범위에 대해 인가를 받는다.
4. 인증 코드 발급
사용자가 인가를 승인하면, 인증 서버는 사용자를 클라이언트 애플리케이션의 리다이렉트 URI로 다시 리다이렉트한다.
이 때 인증 코드가 URI에 포함되어 전달된다.
5. 엑세스 토큰 요청
클라이언트 애플리케이션은 인증코드와 자신의 클라이언트 아이디, 시크릿, 그리고 리다이렉트 URI를 사용하여 인증 서버에게 엑세스 토큰을 요청한다.
6. 엑세스 토큰 발급
인증 서버는 클라이언트 애플리케이션의 요청을 검증하고, 요청이 올바르면 엑세스 토큰을 발급한다.
이제 클라이언트 애플리케이션은 이 액세스 토큰을 사용하여 리소스 서버에게 사용자 정보를 요청할 수 있다.
Implicit Grant (암묵적 승인 방식)
- 주로 클라이언트 사이드 애플리케이션에서 사용된다. (클라이언트 사이드 애플리케이션 : 웹브라우저에서 직접 실행되는 애플리케이션)
- 액세스 토큰이 클라이언트 사이드에 직접 노출되므로 보안상 문제가 있을 수 있다.
- 액세스 토큰의 만료기간을 짧게 설정하여 누출의 위험을 줄일 필요가 있다.
- Refresh Token 사용이 불가능하다.
주요단계
1. 사용자 인증 요청
2. 사용자 인증
3. 사용자 인가
(1-3 에 대한 설명은 권한 부여 승인 코드 방식과 동일하다)
4. 액세스 토큰 발급
사용자가 인가를 승인하면, 인증 서버는 사용자를 클라이언트 애플리케이션의 리다이렉트 URI로 다시 리다이렉트한다.
이 때 엑세스 토큰이 URI의 프래그먼트에 포함되어 전달된다.
Resource Owner Password Credentials Grant (자원 소유자 자격증명 승인 방식)
- 사용자(리소스 소유자)의 ID와 비밀번호를 직접 사용하여 인증하는 방법이다.
- 사용자의 ID와 비밀번호를 애플리케이션에 직접 제공해야 하므로 신뢰할 수 있는 애플리케이션에서만 사용되어야 한다.
주요단계
1. 사용자 인증 요청
클라이언트 애플리케이션은 사용자로부터 ID와 비밀번호를 직접 수집한다.
2. 액세스 토큰 요청
클라이언트 애플리케이션은 수집한 사용자의 ID와 비밀번호를 사용하여 인증 서버에게 액세스 토큰을 요청한다.
이 때, 클라이언트 애플리케이션의 ID와 시크릿도 함께 전송되어 인증 서버는 이를 확인하여 요청의 유효성을 검사한다.
3. 액세스 토큰 발급
인증 서버는 받은 사용자의 ID와 비밀번호를 확인하여 올바르다면 엑세스 토큰을 발급한다.
Client Credentials Grant (클라이언트 자격증명 승인 방식)
- 클라이언트 자체의 자격 증명을 사용하여 액세스 토큰을 얻는 방법이다.
- 클라이언트가 별도의 리소스 소유자의 동의나 인증 없이 서비스를 요청할 때 유용하며, 클라이언트가 서비스를 사용자를 대신하여 사용하는 경우에 주로 사용된다.
- 클라이언트 자체가 리소스 소유자인 경우에 이 방식을 사용한다.
주요단계
1. 액세스 토큰 요청: 클라이언트는 자신의 ID와 비밀번호를 사용하여 인증 서버에게 액세스 토큰을 요청한다.
2. 액세스 토큰 발급: 인증 서버는 클라이언트의 자격증명을 확인하고, 이를 통해 클라이언트의 요청이 유효함을 판단한다. 요청이 유효하면 인증 서버는 액세스 토큰을 발급한다.
