[Spring Security] Oauth 2.0 란?
🪪 OAuth란?
웹 서핑을 하다 보면, Google이나 Facebook 등의 외부 소셜 계정을 기반으로 간편하게 회원가입 및 로그인 할 수 있는 웹 애플리케이션을 쉽게 찾아 볼 수 있다. 외부 소셜계정을 통해 한번의 클릭 만으로 로그인하고, Google Calendar나 Facebook 프로필과 같은 기능을 쉽게 연동할 수 있다.
이때 사용되는 프로토콜이 바로 OAuth다.
OAuth란 사용자가 비밀번호를 제공하지 않고도 다른 웹사이트나 애플리케이션에서 자신의 정보를 안전하게 공유할 수 있도록 하는 표준 접근 위임 프로토콜이다.
OAuth 2.0은 1.0에서 알려진 보안 문제 등을 개선한 버전이다.
🏗️ OAuth 구성 요소
OAuth 시스템은 몇 가지 주요 구성 요소로 이루어져 있으며, 각 요소는 특정 역할을 담당한다.
| 구성 요소 | 설명 |
|---|---|
| Resource Owner | 특정 서비스(Google, Facebook 등)에서 생성되거나 관리되는 데이터, 정보, 기능 등에 대한 소유권을 가지고 있는 사용자이다. 주로 개인정보의 주체를 의미한다. |
| Client | Resource Owner의 자원에 접근하려는 애플리케이션이다. Client는 Authorization Server로부터 Access Token을 발급받아 Resource Server에 요청을 보내고, 필요한 자원에 접근한다. |
| Authorization Server | 사용자의 인증을 수행하고, Client의 요청을 검증하며, Resource Owner의 동의를 얻은 후 Access Token과 Refresh Token을 발급하는 서버이다. |
| Resource Server | 실제 자원을 저장하고 관리하는(Google, Facebook 등) 서버이다. 유효한 Access Token을 가진 Client에게만 자원에 대한 접근을 허용한다. |
| Access Token | Resource Server가 Client에게 발급하는 자격 증명이다. 해당 토큰을 가진 Client는 특정 자원에 대해 제한된 시간 동안 접근할 수 있다. |
| Refresh Token | Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용되는 토큰이다. 자세한 내용은 Access Token & Refresh Token 포스팅을 참고하자. |
추가 중요 개념
| 구성 요소 | 설명 |
|---|---|
| Scope | Resource Server가 제공하는 자원에 대한 접근 권한을 세분화하는 데 사용된다. Client는 필요한 Scope를 명확히 지정해 불필요한 자원에 대한 접근을 막을 수 있다. 예: profile, email, address 등 |
| Authorization Grant | Client가 Resource Server로부터 Access Token을 발급받기 위해 사용하는 인증 매커니즘이다. OAuth 2.0 명세는 네 가지 주요 그랜트 타입을 정의하고 있다. 그에 대한 내용은 밑에서 다시 설명하겠다. |
💡 왜 OAuth가 필요한가?
사용자 정보 보호 강화:
- 비밀번호 노출 방지: 사용자는 자신의 비밀번호를 제3자 애플리케이션에 직접 제공하지 않아도 된다. 이는 해킹이나 데이터 유출 시 발생할 수 있는 피해를 최소화한다.
- 권한 범위 제한: 사용자가 애플리케이션에 부여하는 권한을 명확히 설정할 수 있다. 예를 들어서 프로필 사진만 공유하는 등 세밀한 권한 관리가 가능하다.
사용자 경험 향상:
- 간편한 로그인: 사용자는 기존에 사용하던 계정으로 간편하게 로그인 할 수 있어 편리하다.
- 다양한 서비스 연동: 다양한 서비스와 연동해 더욱 풍부한 기능을 제공할 수 있다.
OAuth는 주로 인가(Authorization)를 위한 프레임워크임을 명확히 할 필요가 있다.
즉, 사용자 자격 증명을 통해 인증하는 것이 아니라, 인가된 엑세스를 제공하는 것이 주된 목적이다.
🕹️ OAuth의 작동방식
기본적인 OAuth 2.0 플로우는 다음과 같다:
- 클라이언트(Client)가 리소스 소유자(Resource Owner)에게 인가를 요청한다.
- 리소스 소유자가 인가를 승인한다.
- 클라이언트가 인가 서버(Authorization Server)로부터 액세스 토큰(Access token)을 받는다.
- 클라이언트가 액세스 토큰을 사용하여 리소스 서버(Resource Server)에서 보호된 리소스에 접근한다.
🔖 OAuth의 주요 인가 그랜트 유형
Authorization Code Grant (인가 코드 그랜트)
- 서버 사이드 애플리케이션에 적합
- 가장 안전한 방식
- 플로우:
- 클라이언트가 사용자를 인가 서버로 리다이렉트
- 사용자가 인증 후 인가 코드를 받음
- 클라이언트가 인가 코드(Authorization Code)로 액세스 토큰을 요청
PKCE(Proof Key for Code Exchange) 도입
인가 코드 그랜트의 보안을 강화하기 위해 PKCE가 도입되었다. 이는 특히 공개 클라이언트(모바일 앱, SPA)에서 인가 코드가 탈취되는 위험을 줄여준다. PKCE는 코드 챌린지와 코드 검증을 통해 코드 탈취 시에도 안전성을 보장한다.
Implicit Grant (암묵적 그랜트)
- 이 방식은 보안 문제로 현재는 사용을 권장하지 않는 플로우이다.
- OAuth 2.1에서는 암묵적 그랜트 플로우가 공식적으로 제외되었다.
- 브라우저에서 토큰이 노출될 수 있는 리스크 때문에 인가 코드 그랜트를 PKCE와 함께 사용하는 것을 권장한다.
리소스 소유자 비밀번호 자격 증명 그랜트
- 신뢰할 수 있는 클라이언트에만 사용
- 사용자 이름과 비밀번호로 직접 액세스 토큰 요청
클라이언트 자격 증명 그랜트
- 클라이언트가 자신의 자격 증명으로 액세스 토큰 요청
- 사용자 컨텍스트가 없는 경우에 사용
OIDC (OpenID Connect 1.0)
앞서 OAuth는 인가를 위한 프레임워크라고 설명하였다.
OAuth 2.0은 사용자 대신 다른 애플리케이션이 사용자의 자원에 접근할 수 있도록 허용하는 매커니즘을 제공하는 것이다.
그렇다면 인증의 경우에는 무엇을 사용해야할까?
바로 OpenID Connect 1.0이다. OIDC는 OAuth 2.0을 기반으로 사용자의 신원을 확인하는 추가적인 기능을 제공하는 단일 로그온(Single Sign-On) 프로토콜이다.
OIDC는 인증과 권한 부여를 모두 담당한다.
OAuth 2.0이 “어떤 애플리케이션이 사용자의 자원에 접근할 수 있을까?”에 대한 질문에 답한다면, OpenID Connect는 “이 사용자는 누구인가”라는 질문에 답하는 것이다.
❓ 여기서 질문 OAuth를 인증 용도로 사용할 수 있는데 왜 OIDC가 필요한 것까?
OIDC는 인증을 위한 표준화된 프로토콜을 제공하지만, OAuth는 인증을 위한 명확한 규격이 없어 구현마다 다를 수 있다. 따라서 인증은 OIDC를 사용하는 것이 좋다.
참고
Leave a comment