OAuth 2.0에 대해

OAuth 2.0은 사용자 인증과 권한 부여를 위한 개방형 표준 프로토콜입니다. 주로 사용자가 애플리케이션에게 자신의 정보를 안전하게 제공하거나 특정 권한을 부여할 때 쓰입니다. 즉, 앱이 사용자 대신 서비스에 접근할 수 있도록 권한을 위임하는 방식을 정의합니다.

---

OAuth 2.0의 등장 배경

• 기존 방식에서는 서비스 간 인증을 위해 ID와 비밀번호를 공유해야 했는데, 보안상 매우 취약했습니다.
• OAuth는 사용자의 비밀번호를 직접 전달하지 않고, 액세스 토큰(Access Token)을 발급하여 제삼자가 제한된 범위에서 접근할 수 있게 해줍니다.

OAuth 2.0 구성 요소
OAuth 2.0은 네 가지 핵심 역할로 이루어집니다. 구성요소와 역할이 다음과 같습니다.

Resource Owner (사용자)	접근을 허용하는 리소스(예: 계정, 사진)의 주인
Client (클라이언트)	사용자 대신 리소스에 접근을 요청하는 응용 프로그램
Authorization Server (인증 서버)	사용자의 인증 및 권한 부여를 처리하고 액세스 토큰 발급
Resource Server (리소스 서버)	보호된 리소스를 관리하며, 인증된 토큰을 통해 접근 허용

OAuth 2.0 용어 정리

✅ Access Token (액세스 토큰)
✔️ 권한이 부여된 리소스에 접근할 때 사용되는 일종의 임시 열쇠입니다.
✔️ 제한된 시간 동안 유효하며, 사용자의 비밀번호가 아닌 토큰을 통해 접근합니다.

✅ Refresh Token (리프레시 토큰)
✔️ 액세스 토큰의 유효기간이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용되는 장기 토큰입니다.

✅ Scope (범위)
✔️ 리소스 접근 권한의 범위를 지정합니다. (예: 읽기, 쓰기, 이메일 접근 등)

✅ Authorization Grant (권한 부여 유형)
✔️ 액세스 토큰을 얻기 위한 승인 프로세스 방식을 나타냅니다.

---

OAuth 2.0 권한 부여 유형
OAuth 2.0에서는 네 가지 주요 권한 부여 유형을 제공합니다.
✅ 인증 코드(Authorization Code) (가장 많이 쓰임)
✔️ 웹 서버 기반의 애플리케이션에서 사용됩니다.
✔️ 리다이렉트 URL을 통해 인증 서버로부터 코드(code)를 받고, 클라이언트가 이 코드를 이용하여 액세스 토큰을 얻습니다.

✅ 암시적 방식(Implicit)
✔️ 클라이언트가 웹 브라우저(자바스크립트 기반) 애플리케이션인 경우 사용합니다.
✔️ 액세스 토큰이 인증 코드 없이 즉시 전달되며, 보안상 현재는 거의 권장되지 않습니다.

✅ 리소스 소유자 암호 자격증명 방식(Resource Owner Password Credentials)
✔️ 신뢰성이 높은 애플리케이션에서 사용자 ID와 비밀번호를 직접 받아 액세스 토큰을 얻습니다.
✔️ 보안 문제로 인해 권장되지 않습니다.

✅ 클라이언트 자격증명 방식(Client Credentials)
✔️ 애플리케이션 자신이 리소스의 소유자일 때 사용되며, 서버 대 서버 통신에서 주로 활용됩니다.
✔️ 사용자 없이 클라이언트가 자신의 ID와 비밀키를 사용해 액세스 토큰을 얻습니다.

---

OAuth 2.0 프로세스 흐름 (인증 코드 방식 기준)
가장 흔하게 사용되는 "Authorization Code" 방식의 흐름을 정리하면 다음과 같습니다.

✅ 클라이언트(애플리케이션)가 사용자에게 권한 요청
✔️ 사용자는 클라이언트를 통해 OAuth 제공자의 인증 서버로 리다이렉트됩니다.

✅ 사용자 인증 및 권한 부여
✔️ OAuth 제공자는 사용자에게 로그인 요청을 하고 권한을 승인받습니다.

✅ 인증 코드 발급
✔️ 사용자가 권한을 승인하면 인증 서버는 클라이언트에게 'Authorization Code'를 발급하여 리다이렉트합니다.

✅ 액세스 토큰 요청
✔️ 클라이언트는 발급받은 인증 코드와 클라이언트의 비밀키(client secret)를 이용해 인증 서버에 액세스 토큰을 요청합니다.

✅ 액세스 토큰 발급
✔️ 인증 서버가 클라이언트의 요청을 확인 후 액세스 토큰과 리프레시 토큰(옵션)을 제공합니다.

✅ 리소스 접근
✔️ 클라이언트는 발급받은 액세스 토큰을 사용하여 리소스 서버에 요청을 보냅니다.

OAuth 2.0의 장점과 단점

✅ 장점
✔️ 사용자 비밀번호를 타 애플리케이션과 공유하지 않기 때문에 보안성이 높습니다.
✔️ 권한의 범위를 명확하게 지정할 수 있어 관리가 편리합니다.
✔️ 표준 프로토콜이므로 다양한 플랫폼과 서비스에서 쉽게 구현 가능하고 상호운용성이 뛰어납니다.

✅ 단점
✔️ 구현이 비교적 복잡하여 이해 및 설정 과정에서 실수가 발생할 수 있습니다.
✔️ 액세스 토큰을 제대로 관리하지 않으면 보안상 위험이 될 수 있습니다.

---

OAuth 2.0 기반 시스템 적용 사례

🔷 1단계: 요구사항 분석 및 설계
사내 시스템에서 OAuth 2.0을 도입하는 이유와 목적을 명확히 합니다.

• 외부 서비스와의 연동을 위한 인증 필요성
• 사내 시스템 간의 싱글사인온(SSO) 기능 구현
• 시스템 보안 강화 및 계정 관리 편의성 확보

이 단계에서 정의할 주요 사항은

・ 사용할 OAuth 2.0 권한 부여 유형 (대개 Authorization Code 방식 추천)
・ 액세스 토큰 및 리프레시 토큰의 유효기간 정책
・ 사용자 인증 방침 (ID/PW 방식, LDAP 또는 AD 연계 등)
・ 접근 권한 관리 정책 (Scope)

---

🔷 2단계: OAuth 2.0 서버 구축 (인증 및 권한부여 서버)
사내에서 OAuth 2.0을 제공하기 위한 인증 서버를 별도로 구축하거나, 기존 시스템에 OAuth 기능을 추가합니다.
📌 OAuth 2.0 서버로 자주 사용하는 오픈소스 도구 예시

도구	설명
Keycloak	Java 기반, OAuth 2.0 및 OpenID Connect 지원, LDAP/AD 연계 쉬움
Spring Authorization Server	Java Spring 기반, 커스터마이징 쉬움, Spring 생태계와 호환성 높음
IdentityServer4	.NET Core 기반으로 구축된 서버
Auth0, Okta (상용)	SaaS 기반의 OAuth 및 SSO 서비스 (편의성 우수, 유지보수 최소화 가능)

• 권장사항: Keycloak 또는 Spring Authorization Server를 사용하는 것이 국내 사내 환경에서 일반적입니다.

---

🔷 3단계: OAuth 2.0 인증 서버의 작동 방식
OAuth 서버의 기본적인 처리 흐름

1. 클라이언트 등록 및 관리
   • 사내 시스템의 각 서비스가 OAuth 서버에 클라이언트로 등록됩니다.
   • 클라이언트 ID, 클라이언트 비밀번호(Client Secret), 리다이렉트 URL 관리
2. 사용자 인증 및 권한 부여
   • 사용자가 특정 서비스에 접속하면 OAuth 서버가 사용자 인증 수행
   • 인증 완료 후 사용자에게 서비스 접근 권한 승인 여부 확인
3. 인증 코드(Authorization Code) 발급
   • 사용자가 권한을 승인하면 OAuth 서버가 클라이언트에 인증 코드 발급 및 전달 (Redirect URL을 통해 전달)
4. 액세스 토큰 발급
   • 클라이언트가 인증 서버에 인증 코드와 함께 액세스 토큰 요청
   • 인증 서버는 클라이언트의 인증 코드와 클라이언트 Secret 확인 후, 액세스 토큰과 리프레시 토큰 제공
5. 토큰 검증 및 리소스 접근
   • 발급된 액세스 토큰을 이용하여 사내 리소스 서버가 접근 권한을 검증하고 승인 여부 결정

---

🔷 4단계: 리소스 서버의 구축과 작동 방식
사내 각 시스템은 OAuth 서버로부터 받은 액세스 토큰을 검증한 후 리소스에 접근할 수 있도록 허용합니다.
리소스 서버의 작동 방식 예시

• 토큰 검증
  • 클라이언트(애플리케이션)는 API 호출 시 액세스 토큰을 헤더(Authorization Header)에 담아 전달
  • 리소스 서버는 OAuth 인증 서버가 제공한 공개키 또는 토큰 검증 API를 통해 액세스 토큰의 유효성 검증
• 권한 범위(Scope) 검증
  • 액세스 토큰 내부에는 Scope가 정의되어 있으며, 리소스 서버는 Scope를 기반으로 접근 권한을 세부적으로 관리
• 리소스 제공
  • 액세스 토큰이 유효하고 권한 범위 내이면 리소스 제공, 아니면 오류 응답(401 Unauthorized 등)을 반환

---

🔷 5단계: 클라이언트 애플리케이션의 처리 방법
클라이언트 애플리케이션은 다음 역할을 수행합니다.

• OAuth 서버에 클라이언트 등록 및 설정
• 사용자 인증 요청을 OAuth 서버로 리다이렉트 처리
• 인증 코드로 액세스 토큰 요청 처리
• 발급받은 액세스 토큰 관리 및 갱신(Refresh Token 사용)

---

🔷 6단계: 보안 고려 사항 및 권장 설정
OAuth 2.0 시스템 구축 시 중요한 보안 권장 사항은 다음과 같습니다.

• 액세스 토큰의 유효 기간 제한 (예: 15분~1시간)
• 리프레시 토큰의 긴 유효기간 설정과 안전한 저장 관리 (암호화된 DB 저장)
• HTTPS/TLS 사용 필수
• 클라이언트 Secret의 안전한 보관 및 주기적 변경
• 토큰 발급 시 JWT(JSON Web Token)를 활용하여 발급 권장 (검증 효율성과 범용성 확보)

🔷 최종 구성도의 예시

[사용자]  
    ↓  
[클라이언트 애플리케이션] → (인증 요청) → [OAuth 인증 서버]
    ↑                                      ↓
(리소스 요청) ← (토큰 반환) ← (토큰 발급)
    ↓                                     
[리소스 서버] ← (토큰 검증 및 리소스 제공)

🔷 사내 시스템에 도입 시 최적 방안 정리

요소	추천 사항
권한 부여 유형	Authorization Code 방식
서버 구성	Keycloak 또는 Spring Authorization Server 권장
토큰 유형	JWT(JSON Web Token)
프로토콜	HTTPS/TLS
사용자 인증 방식	LDAP/AD 연계 또는 기존 사내 ID 관리 시스템 연동
접근제어	Scope 기반의 세부적인 권한 관리

OAuth 2.0 서버를 사내에 구축하면 보안성과 효율성을 동시에 높일 수 있고, 유지보수성 또한 향상됩니다. 처음에는 다소 복잡해 보일 수 있지만, 명확한 설계와 표준을 따라 구축하면 안정적인 인증 시스템 운영이 가능합니다.