[Kubernetes] OAuth 개념

OAuth

OAuth(Open Authorization)은 API 보안을 위해 등장한 오픈 표준(Open Standard) 프로토콜임.

사용자가 애플리케이션(클라이언트)에게 자신의 자격 증명(예: 비밀번호 등)을 직접 제공하지 않고도 제3의 서비스(리소스 서버)에 접근할 수 있도록 “권한 위임(Authorization Delegation)”을 가능하게 하는 체계임.

주로 “소셜 로그인” 방식이나, 다른 플랫폼 간 데이터 공유·접근을 위임할 때 활용됨.

최근에는 OAuth 2.0이 가장 널리 쓰이며, OAuth 1.0a는 이전 버전이지만 보안상의 특징 덕분에 일부 환경에서 쓰이기도 함.

 

OAuth의 주요 개념 및 용어

1. Resource Owner(리소스 소유자)

사용자를 의미함.

실제로 보호된 자원(Protected Resource)에 대한 소유 권한을 가지고 있음.

 

2. Client(클라이언트)

리소스 소유자를 대신해 보호된 자원에 접근하고자 하는 애플리케이션 또는 서비스임.

예를 들어, 웹 애플리케이션, 모바일 앱, 서버 애플리케이션 등.

 

3. Authorization Server(인증/인가 서버)

권한 부여를 담당하는 서버임.

사용자 인증과 클라이언트 권한 검증을 수행하여 Access Token을 발급함.

 

4. Resource Server(리소스 서버)

보호된 자원을 호스팅하는 서버(또는 API)임.

Authorization Server가 발급한 Access Token을 검증하고, 유효한 토큰을 기반으로 클라이언트에 자원 접근을 허용함.

 

5. Access Token(액세스 토큰)

클라이언트가 Resource Server에 접근할 수 있도록 권한을 대행해주는 짧은 기간 동안 유효한 자격 증명임.

일반적으로 JWT(JSON Web Token) 등을 사용할 수 있으며, 만료 기간(TTL)이 짧게 설정됨.

 

6. Refresh Token(리프레시 토큰)

Access Token의 유효 기간이 만료되었을 때, 클라이언트가 다시 사용자 인증 절차 없이(혹은 최소한의 절차만으로) Access Token을 재발급받기 위해 사용하는 토큰임.

Refresh Token의 보안 관리가 매우 중요하며, 일반적으로 서버 측에 안전하게 저장하는 방식이 요구됨.

(특히 OAuth 2.0 스펙 및 보안 모범사례에 따를 경우)

 

OAuth 2.0의 작동 흐름 (Grant Type 별)

OAuth 2.0에서는 Grant Type이라는 개념으로 다양한 인증·인가 플로우를 지원함.

용도와 시나리오에 따라 서로 다른 Grant Type을 사용하여, 각각 보안 수준과 편의성을 조절할 수 있음.

 

OAuth 2.0의 작동 흐름 (Grant Type 별) - Authorization Code Grant

가장 많이 사용되는 플로우임.

서버 사이드(백엔드) 애플리케이션이 클라이언트로 동작하는 경우 많이 채택됨.

 

1. 사용자 → 클라이언트

사용자가 클라이언트(웹 애플리케이션 등)에서 ‘소셜 로그인’ 또는 ‘권한 위임’ 기능을 실행함.

클라이언트는 Authorization Server로 사용자를 이동시켜 인가를 요청함.

 

2. 사용자 인증 → Authorization Server

사용자가 Authorization Server(예: 구글 로그인 서버)에 로그인 또는 권한 부여 동의를 수행함.

성공 시, Authorization Server는 Authorization Code(짧은 수명의 1회성 코드)를 클라이언트의 리다이렉트 URI로 전달함.

 

3. 클라이언트 → Authorization Server

클라이언트(서버 측)는 전달받은 Authorization Code와 함께 클라이언트 자격(Client ID, Client Secret 등)을 인증 서버에 보냄.

이때 HTTPS 통신을 통해서만 전달하며, 유효성 검사를 통과하면 Access Token(필요 시 Refresh Token 포함)을 발급받음.

 

4. Access Token 사용 → Resource Server 접근

이후 클라이언트는 받은 Access Token을 사용하여 Resource Server의 API를 호출함.

Resource Server는 토큰을 검증하고, 유효하면 보호된 자원에 접근을 허용함.

 

Authorization Code Grant는 토큰을 직접 브라우저 프론트엔드가 아닌 백엔드 서버에서 교환하므로, 클라이언트 시크릿(Client Secret)을 안전하게 유지할 수 있음.

가장 많이 사용되는 표준 플로우이며, Refresh Token 발급도 가능하여 장기 세션 구현에 유리함.

 

OAuth 2.0의 작동 흐름 (Grant Type 별) - Implicit Grant

OAuth 2.0의 초기 스펙에서 클라이언트가 브라우저 기반(JS) 애플리케이션이고, 별도의 백엔드 서버가 없이 동작하거나, 직접 토큰을 얻어야 하는 상황을 고려하여 만들어진 방식임.

그러나 보안 이슈(Access Token이 URL 해시 파라미터로 직접 노출 등)로 인해 현재는 사용이 권장되지 않고, 점차 대체되고 있음.

 

동작은 다음과 같음.

1. Authorization Server로부터 Access Token이 바로 브라우저 리다이렉트 URI의 해시 파라미터에 포함되어 돌아옴.

2. 별도의 Authorization Code 단계를 거치지 않기 때문에 토큰 유출 위험이 클 수 있음.

3. Refresh Token 발급이 불가능함.

 

OAuth 2.0의 작동 흐름 (Grant Type 별) - Resource Owner Password Credentials Grant

사용자의 아이디/비밀번호를 클라이언트가 직접 받아 Authorization Server에 전달하여, Access Token을 발급받는 방식임.

특정 환경(예: 사내 인증 시스템, 잘 통제된 클라이언트 앱)에서만 제한적으로 사용됨.

사용자 자격 증명이 노출될 수 있고, 클라이언트가 이를 직접 취급하게 되므로 보안상 위험도가 큼.

표준 OAuth 2.0 사용 사례에서는 보안을 위해 점차 사용이 줄고 있음.

 

OAuth 2.0의 작동 흐름 (Grant Type 별) - Client Credentials Grant

클라이언트 자신이 보호된 리소스에 접근해야 하는 경우(예: 마이크로서비스 간 통신) 사용됨.

사용자는 개입되지 않음.

클라이언트와 Authorization Server 간의 Machine-to-Machine(M2M) 통신에서 클라이언트는 자신의 Client ID와 Client Secret으로 Access Token을 발급받음.

예를 들어, 백엔드 서비스가 다른 백엔드 서비스 API를 호출해야 하는 경우.

 

OAuth 2.0의 작동 흐름 (Grant Type 별) - PKCE(Proof Key for Code Exchange)

PKCE는 모바일·SPA(Single Page Application) 등 Public Client 환경에서 Authorization Code Grant를 보다 안전하게 사용할 수 있도록 확장한 방식임.

클라이언트가 Authorization Code를 교환하는 단계에서, Code Challenge와 Code Verifier라는 값을 이용해 토큰 탈취 위험을 줄임.

브라우저 기반 애플리케이션 및 모바일 앱에서도 Client Secret 없이 안전하게 Authorization Code Grant를 사용할 수 있도록 지원함.

현재 소셜 로그인 등 여러 서비스에서 PKCE를 필수로 요구하는 추세임.

 

Access Token의 형태

OAuth 2.0 명세에서는 Access Token의 형식에 제한이 없음.

JWT(JSON Web Token)가 사실상 표준처럼 활용됨.

JWT 기반의 Access Token은 다음과 같은 구조를 가짐.

 

HEADER.PAYLOAD.SIGNATURE

Header: 알고리즘(typ, alg 등) 정보를 담고 있음

Payload: 실제 유저 식별자(sub), 클라이언트 권한 범위(scope), 만료 시간(exp) 등 정보 포함

Signature: 헤더와 페이로드를 조합해 비밀키(또는 공개키/비밀키 쌍)로 서명한 값

 

1. 장점

Resource Server가 Authorization Server에 매번 문의하지 않고도, 자체적으로 Signature를 검증해 토큰의 무결성과 만료 여부를 확인 가능(Stateless).

확장성이 높고, 마이크로서비스 환경에서 활발히 사용됨.

Base64URL 인코딩으로 비교적 가볍고 전송이 용이.

 

2. 주의 사항

민감한 데이터를 Payload에 직접 담으면 누구나 쉽게 디코딩할 수 있으므로(서명 != 암호화), 개인정보나 비밀정보는 넣으면 안 됨.

JWT의 만료 기간이 길면 중간에 무효화하기 어렵고 보안 취약점이 될 수 있으므로, Refresh Token 전략과 Access Token 짧은 TTL 전략을 함께 사용해야 함.

 

Refresh Token

서버 측에서 안전하게 보관해야 하며, 유출될 경우 장기적으로 Access Token을 재발급받을 수 있으므로 위험함.

보통 Refresh Token을 재발급받는 로직에서 토큰 재사용 검증(토큰 바인딩, 세션 추적 등)을 적용하여 도난 또는 재사용 공격을 방지함.

PKCE 사용, HTTPS 사용, 저장소 보안(브라우저의 경우 Secure, HttpOnly 쿠키 등), 서버 측 세션관리 등 종합적인 보안 고려가 필수임.

 

보안 고려 사항

1. HTTPS 사용

OAuth 2.0에서 Token 교환, Authorization Code 교환 등 모든 트래픽은 반드시 TLS/SSL(HTTPS)로 보호되어야 함.

 

2. Client Secret 보안

공개적으로 배포되는 애플리케이션(SPA, 모바일 앱)에서는 Client Secret을 안전하게 감출 수 없으므로, PKCE와 같은 방식을 사용해야 함.

서버 사이드 애플리케이션은 Secret을 안전하게 서버에만 보관해야 함.

 

3. Token 스코프(Scope) 최소화

“최소 권한 원칙(Principle of Least Privilege)”에 따라, 발급되는 Access Token이 너무 광범위한 권한을 가지지 않도록 제한해야 함.

 

4. Token 유효기간 관리

Access Token은 짧은 TTL을 주어 유출 시 피해를 최소화함.

Refresh Token을 통한 장기 인증 시, 재발급 로직에 보안 절차(사용자 재확인, MFA 등)를 강화할 수 있음.

 

5. Revoke(무효화) 시나리오 고려

토큰 탈취 등 보안 사고 발생 시, Authorization Server나 Resource Server가 토큰을 무효화할 수 있는 기제가 필요함.

데이터베이스나 중앙 관리 시스템에서 토큰 상태를 추적하고, 필요 시 블랙리스트 처리 등을 할 수 있어야 함.

 

실제 구현 시 주의할 점 및 확장

1. 인증 방식과 인가 방식을 적절히 구분

OAuth는 원래 “권한 위임”을 위한 프로토콜이지만, 최근에는 로그인(인증)에도 널리 쓰임.

OpenID Connect(OIDC)는 OAuth 2.0 위에 “인증” 레이어를 확장한 표준이며, 사용자 프로필을 안전하게 조회할 수 있게 해줌.

 

2. SPA/모바일 앱에서의 보안 강화를 위한 PKCE

Implicit Grant는 사용을 지양하고, Authorization Code Grant + PKCE 조합을 권장함.

 

3. Token 저장 위치

브라우저 환경에서 액세스 토큰을 로컬 스토리지에 저장하면 XSS 공격에 노출될 위험이 큼.

Cookie를 사용할 경우 Secure, HttpOnly, SameSite 속성 등을 활성화해야 함.

모바일 앱은 시스템 Keychain/Keystore 등을 통해 보관하여 안전성을 높여야 함.

 

4. Token 무효화(Revocation)와 로깅

토큰 사용 로그, IP, 디바이스 정보를 추적하여 이상 패턴을 감지하면 즉시 해당 토큰을 만료 처리하는 대응책을 마련해야 함.

 

5. Role-Based Access Control(RBAC), Attribute-Based Access Control(ABAC) 등과의 연계

OAuth 토큰에는 사용자 식별자, 권한 정보(roles, scopes 등)를 담아 전송할 수 있으며, 세분화된 접근 통제를 구현할 수 있음.

 

정리

OAuth(특히 OAuth 2.0)는 오늘날 API 보안과 권한 위임의 사실상 표준으로 자리 잡음.

소셜 로그인부터 마이크로서비스 간 통신까지 광범위하게 활용됨.

Authorization Code Grant + PKCE를 사용하면 상당히 견고한 보안 구조를 구현할 수 있음.

Access Token과 Refresh Token의 사용주기를 효율적으로 관리하는 전략이 중요함.

동시에 OpenID Connect, JWT, TLS, 토큰 무효화 시스템 등 인증·인가 전체 생태계를 충분히 이해하고 운영해야 안정적인 보안을 실현할 수 있음.

OAuth는 지속적으로 발전하고 있으며, 실제 서비스에 도입할 때는 베스트 프랙티스와 보안 이슈를 철저히 준수해야 함.

이러한 점들을 종합적으로 고려하여 설계하면, 확장성과 보안을 모두 만족하는 OAuth 기반 권한 위임 환경을 구현할 수 있음.