📑 목차
- 도입: 현대 웹 서비스 보안의 핵심, 인증/인가 시스템의 중요성
- OAuth 2.0 이해: 권한 위임의 표준 프로토콜
- OAuth 2.0의 핵심 역할과 구성 요소
- 주요 Grant Type 및 동작 방식
- OpenID Connect 이해: OAuth 2.0 위에 구축된 인증 레이어
- OAuth 2.0과 OpenID Connect의 관계 및 차이점
- OIDC의 핵심 요소: ID 토큰과 UserInfo Endpoint
- OAuth 2.0 및 OpenID Connect 기반 시스템 설계 고려사항
- 클라이언트 등록 및 관리 전략
- 토큰 관리 및 보안
- 스코프 (Scope) 및 클레임 (Claim) 설계
- 구현 가이드: 실제 시스템 구축을 위한 단계별 접근
- 개발 스택 선택 및 도구 활용
- Authorization Code Flow with PKCE 구현 상세 예시
- 보안 강화 및 운영 전략
- 주요 보안 위협 및 대응
- 로깅 및 모니터링
- 정기적인 보안 감사 및 업데이트
- 결론: 안전하고 효율적인 인증/인가 시스템의 완성
Image by Kranich17 on Pixabay
도입: 현대 웹 서비스 보안의 핵심, 인증/인가 시스템의 중요성
오늘날 대부분의 웹 서비스는 사용자 데이터와 민감한 정보에 대한 접근을 제어해야 합니다. 단일 서비스 내에서의 사용자 이름과 비밀번호 기반 인증은 비교적 단순할 수 있으나, 여러 서비스 간의 통합, 서드파티 애플리케이션 연동, API 기반 통신이 보편화되면서 더욱 정교하고 표준화된 인증 및 인가 메커니즘이 요구됩니다. 이러한 복잡성 속에서 OAuth 2.0과 OpenID Connect (OIDC)는 현대 웹 및 모바일 환경에서 가장 널리 사용되는 표준으로 자리 잡았습니다. 이 두 프로토콜은 단순히 사용자를 식별하는 것을 넘어, 자원에 대한 접근 권한을 안전하게 위임하고 관리하는 데 핵심적인 역할을 수행합니다. 본 가이드는 이 두 가지 중요한 표준을 기반으로 안전하고 확장 가능한 인증 및 인가 시스템을 구현하기 위한 심층적인 통찰과 실용적인 접근법을 제시합니다.
많은 개발자와 아키텍트가 이 두 프로토콜의 개념과 동작 방식에 대해 혼란을 겪는 경우가 많습니다. 특히, OAuth 2.0이 인가(Authorization) 프레임워크인 반면, OIDC는 그 위에 구축된 인증(Authentication) 레이어라는 점을 명확히 이해하는 것이 중요합니다. 이 글을 통해 각 프로토콜의 본질적인 목적과 상호 관계를 파악하고, 실제 시스템 설계 및 구현 과정에서 발생할 수 있는 주요 고려사항과 모범 사례를 습득할 수 있을 것으로 기대됩니다.
OAuth 2.0 이해: 권한 위임의 표준 프로토콜
OAuth 2.0은 자원 소유자의 자원에 대한 접근 권한을 제3자 클라이언트에게 안전하게 위임하기 위한 인가 프레임워크입니다. 여기서 중요한 점은 OAuth 2.0이 직접적인 사용자 인증을 담당하지 않는다는 것입니다. 대신, 사용자가 특정 클라이언트에게 자신의 특정 자원(예: 사진, 연락처, 프로필 정보)에 접근할 수 있는 권한을 부여하도록 돕는 메커니즘을 제공합니다. 이는 사용자가 자신의 계정 비밀번호를 제3자 클라이언트와 공유할 필요 없이 안전하게 권한을 위임할 수 있게 합니다.
OAuth 2.0의 핵심 역할과 구성 요소
OAuth 2.0은 네 가지 주요 역할로 구성됩니다:
- 자원 소유자 (Resource Owner): 보호된 자원의 소유자이며, 클라이언트에게 자원 접근 권한을 부여할 수 있는 개인 또는 애플리케이션입니다. 일반적으로 최종 사용자입니다.
- 클라이언트 (Client): 자원 소유자로부터 권한을 위임받아 보호된 자원에 접근하려는 애플리케이션입니다. 웹 애플리케이션, 모바일 앱, 데스크톱 앱 등 다양합니다.
- 인가 서버 (Authorization Server): 자원 소유자를 인증하고, 클라이언트에게 접근 권한을 부여(인가)하는 서버입니다. 성공적인 인가 후 접근 토큰(Access Token)을 발급합니다.
- 자원 서버 (Resource Server): 보호된 자원을 호스팅하는 서버입니다. 클라이언트가 접근 토큰을 제시하면 해당 토큰의 유효성을 검증하고 자원 접근을 허용합니다.
주요 Grant Type 및 동작 방식
OAuth 2.0은 다양한 Grant Type(인가 부여 방식)을 제공하여 클라이언트의 유형과 사용 시나리오에 따라 적절한 흐름을 선택할 수 있도록 합니다. 가장 널리 사용되는 Grant Type은 다음과 같습니다.
- Authorization Code Grant:가장 안전하고 권장되는 방식이며, 서버 사이드 웹 애플리케이션에 적합합니다. 클라이언트는 인가 코드를 받은 후, 이를 인가 서버에 직접 전달하여 접근 토큰으로 교환합니다. 이 과정에서 클라이언트 비밀(Client Secret)이 사용되어 보안성이 높습니다. 인가 코드는 한 번만 사용 가능하며 유효 기간이 짧아 중간에 탈취되어도 즉시 재사용하기 어렵습니다.특히, PKCE (Proof Key for Code Exchange) 확장을 함께 사용하여 Public Client (모바일 앱, SPA 등)에서 Authorization Code Grant의 보안을 더욱 강화할 수 있습니다. PKCE는 인가 코드 가로채기 공격(Authorization Code Interception Attack)을 방지하는 데 효과적입니다.
1. 클라이언트가 자원 소유자를 인가 서버로 리다이렉트 (인가 요청). 2. 자원 소유자가 인가 서버에서 인증 및 권한 부여 동의. 3. 인가 서버가 클라이언트에게 인가 코드 발급 및 리다이렉트. 4. 클라이언트가 인가 코드를 인가 서버에 전달 (클라이언트 비밀 포함). 5. 인가 서버가 접근 토큰 및 갱신 토큰(Refresh Token) 발급. 6. 클라이언트가 접근 토큰을 사용하여 자원 서버에 요청.- Client Credentials Grant:클라이언트가 자원 소유자 없이 자신의 자격 증명(Client ID, Client Secret)만을 사용하여 접근 토큰을 요청하는 방식입니다. 주로 서버 간 통신, 머신-투-머신(M2M) 인증 등 애플리케이션 자체가 자원 소유자인 시나리오에 사용됩니다.
- Refresh Token:접근 토큰의 유효 기간이 만료되었을 때, 사용자의 재인증 없이 새로운 접근 토큰을 얻기 위해 사용됩니다. 갱신 토큰은 일반적으로 접근 토큰보다 긴 유효 기간을 가지며, 안전하게 보관되어야 합니다. 갱신 토큰의 재사용 방지 및 폐기 메커니즘 구현이 중요합니다.
Implicit Grant는 보안 취약점(토큰 탈취 위험성)으로 인해 더 이상 권장되지 않으며, Public Client에서는 PKCE를 포함한 Authorization Code Grant를 사용하는 것이 모범 사례로 판단됩니다.
OpenID Connect 이해: OAuth 2.0 위에 구축된 인증 레이어
OAuth 2.0은 인가 프레임워크이지만, 사용자 인증(Authentication)에 대한 명확한 표준을 제공하지 않습니다. 즉, 클라이언트는 접근 토큰을 통해 자원에 접근할 수 있지만, "현재 로그인한 사용자가 누구인지"에 대한 정보를 직접적으로 얻을 수는 없습니다. 이러한 문제를 해결하기 위해 OpenID Connect (OIDC)가 등장했습니다. OIDC는 OAuth 2.0 프로토콜 위에 구축된 단순한 아이덴티티 레이어로, 클라이언트가 최종 사용자의 신원을 확인할 수 있도록 설계되었습니다.
OAuth 2.0과 OpenID Connect의 관계 및 차이점
OIDC는 OAuth 2.0의 확장으로 볼 수 있습니다. OIDC는 OAuth 2.0의 인가 흐름을 재사용하면서, ID 토큰(ID Token)이라는 새로운 토큰과 UserInfo Endpoint를 추가하여 인증 기능을 제공합니다. 핵심적인 차이점은 다음과 같습니다.
| 특징 | OAuth 2.0 | OpenID Connect |
|---|---|---|
| 주요 목적 | 권한 위임 (Authorization) | 사용자 신원 확인 (Authentication) |
| 핵심 토큰 | Access Token (접근 토큰) | ID Token (ID 토큰), Access Token |
| 제공 정보 | 자원 접근 권한 | 사용자 신원 정보 (e.g., 이름, 이메일, 고유 ID) |
| 프로토콜 스택 | 독립적인 인가 프레임워크 | OAuth 2.0 위에 구축된 레이어 |
OIDC의 핵심 요소: ID 토큰과 UserInfo Endpoint
OIDC는 다음 두 가지 주요 요소를 통해 사용자 인증을 가능하게 합니다:
- ID 토큰 (ID Token):JWT(JSON Web Token) 형식으로 인코딩된 토큰으로, 사용자의 신원 정보(Claims)를 포함합니다. 클라이언트는 이 토큰을 디코딩하고 서명을 검증하여 사용자의 신원을 안전하게 확인할 수 있습니다. 주요 클레임으로는
iss(발급자),sub(사용자 고유 식별자),aud(대상 클라이언트),exp(만료 시간),iat(발급 시간) 등이 있습니다. ID 토큰의 검증은 OIDC 시스템 구현에서 가장 중요한 보안 단계 중 하나입니다. - UserInfo Endpoint:인가 서버에서 제공하는 RESTful API 엔드포인트로, 접근 토큰을 사용하여 요청하면 사용자의 추가적인 프로필 정보(이름, 이메일, 프로필 사진 등)를 JSON 형태로 반환합니다. ID 토큰에 포함된 클레임은 주로 필수적인 정보이며, UserInfo Endpoint는 더 많은 사용자 정보를 동적으로 얻을 때 사용됩니다.
OIDC는 OAuth 2.0의 scope 파라미터에 openid라는 특별한 값을 추가하여 OIDC 흐름을 시작합니다. 또한, profile, email, address, phone 등의 스코프를 통해 클라이언트가 어떤 사용자 정보를 요청할지 명시할 수 있습니다.
Image by u_h0yvbj97 on Pixabay
OAuth 2.0 및 OpenID Connect 기반 시스템 설계 고려사항
견고한 인증/인가 시스템을 설계하기 위해서는 프로토콜의 이해를 넘어선 심층적인 고려가 필요합니다. 특히 보안, 확장성, 유용성 측면에서 신중한 접근이 요구됩니다.
클라이언트 등록 및 관리 전략
- 동적 클라이언트 등록 (Dynamic Client Registration):클라이언트가 인가 서버에 API 호출을 통해 자동으로 등록될 수 있도록 하는 OIDC의 확장입니다. 이는 대규모 서비스에서 클라이언트 관리를 자동화하고 확장성을 높이는 데 유용합니다. 하지만 악의적인 클라이언트 등록을 방지하기 위한 강력한 인증 및 인가 메커니즘이 동반되어야 합니다.
- 정적 클라이언트 등록:관리자가 인가 서버에 클라이언트 정보를 직접 등록하는 방식입니다. 보안성이 높지만, 클라이언트 수가 많아질수록 관리 부담이 증가합니다. 일반적으로 서비스 시작 단계나 소수의 신뢰할 수 있는 클라이언트에 사용됩니다.
- 리다이렉션 URI (Redirect URI) 관리:클라이언트 등록 시 반드시 유효한 리다이렉션 URI를 명시하고, 인가 서버는 이 목록에 없는 URI로의 리다이렉트를 엄격히 거부해야 합니다. 이는 인가 코드 가로채기 공격과 같은 보안 위협을 방지하는 데 필수적입니다.
토큰 관리 및 보안
발급되는 토큰(Access Token, Refresh Token, ID Token)의 생명주기 관리와 보안은 시스템의 전반적인 보안 수준을 결정합니다.
- 토큰 형식:대부분의 구현에서 JWT (JSON Web Token) 형식이 사용됩니다. JWT는 자체 포함적(self-contained)이며, 서명(Signature)을 통해 무결성을 보장할 수 있어 효율적입니다. 하지만 JWT는 암호화되지 않는 한 민감한 정보를 직접 포함해서는 안 됩니다.
- 토큰 유효 기간:Access Token은 짧은 유효 기간(예: 5분~60분)을 갖도록 설계하여 탈취 시 피해를 최소화해야 합니다. 반면 Refresh Token은 더 긴 유효 기간을 가질 수 있지만, 이를 안전하게 저장하고 관리하는 것이 중요합니다. Refresh Token은 반드시 일회성 사용(One-time use) 또는 재사용 감지(Replay Detection) 메커니즘을 적용하여 탈취 후 재사용되는 것을 방지해야 합니다.
- 토큰 저장:클라이언트 측에서 토큰을 저장할 때는 다음과 같은 보안 고려사항이 있습니다:
- 웹 애플리케이션 (SPA): Access Token은
localStorage나sessionStorage에 저장될 수 있으나 XSS 공격에 취약합니다.HttpOnly및Secure플래그가 설정된 쿠키에 저장하는 것이 더 안전한 방식으로 판단되지만, CSRF 공격에 대한 추가적인 방어가 필요합니다. Refresh Token은 별도의 안전한 저장소(예: 서버 측 세션, 암호화된 쿠키)에 저장하거나, 웹 환경에서는 사용하지 않는 것을 고려할 수 있습니다. - 모바일 앱: OS에서 제공하는 안전한 저장소(예: iOS Keychain, Android KeyStore)를 사용하는 것이 모범 사례입니다.
- 웹 애플리케이션 (SPA): Access Token은
- 토큰 폐기 (Revocation):사용자 로그아웃, 비밀번호 변경, 보안 침해 발생 시 Access Token 및 Refresh Token을 즉시 폐기할 수 있는 메커니즘(예: Revocation Endpoint)을 구현해야 합니다. 이는 탈취된 토큰의 악용을 막는 데 필수적입니다.
스코프 (Scope) 및 클레임 (Claim) 설계
스코프는 클라이언트가 요청하는 접근 권한의 범위를 정의합니다 (예: profile, email, read:photos). 클레임은 ID 토큰이나 UserInfo Endpoint를 통해 제공되는 사용자의 특정 속성 정보입니다 (예: name, preferred_username, zoneinfo). 스코프와 클레임을 세밀하게 설계하여 클라이언트가 필요한 최소한의 권한과 정보만을 요청하도록 유도하는 최소 권한 원칙(Principle of Least Privilege)을 준수해야 합니다. 이는 사용자 개인 정보 보호 및 시스템 보안 강화에 기여합니다.
구현 가이드: 실제 시스템 구축을 위한 단계별 접근
OAuth 2.0 및 OpenID Connect 기반 시스템을 직접 구현하는 것은 복잡할 수 있으므로, 기존의 잘 검증된 라이브러리나 프레임워크를 활용하는 것이 일반적입니다.
개발 스택 선택 및 도구 활용
- 인가 서버 (Authorization Server) 구현:직접 구현하는 것은 보안 취약점 발생 가능성이 높으므로, Keycloak, Auth0, Okta와 같은 상용 또는 오픈소스 IDaaS (Identity as a Service) 솔루션을 활용하는 것이 강력히 권장됩니다. 이들 솔루션은 OAuth 2.0 및 OIDC 표준을 완벽하게 지원하며, 사용자 관리, 토큰 관리, 다단계 인증(MFA) 등 다양한 보안 기능을 제공합니다. 스프링 개발 스택의 경우 Spring Authorization Server를 사용하여 직접 구축하는 것도 가능하나, 상당한 전문 지식과 노력이 필요합니다.
- 클라이언트 (Client) 구현:클라이언트 애플리케이션에서는 각 언어 및 프레임워크에서 제공하는 OAuth 2.0/OIDC 클라이언트 라이브러리를 사용합니다. 예를 들어, Spring Boot 애플리케이션에서는 Spring Security OAuth2 Client 모듈을 활용할 수 있습니다. Node.js에서는
passport-oauth2, React/Angular에서는oidc-client-js등이 있습니다. - 자원 서버 (Resource Server) 구현:자원 서버는 클라이언트로부터 받은 Access Token의 유효성을 검증하고, 토큰에 포함된 스코프나 클레임을 기반으로 인가 결정을 내립니다. Spring Security는 JWT Access Token을 검증하고, 이를 통해 인증된 사용자 정보를 SecurityContext에 저장하는 기능을 제공합니다.위 예시에서
issuer-uri는 인가 서버의 URI를 나타내며, Spring Security는 이 URI를 통해 인가 서버의 공개 키를 가져와 Access Token의 서명을 검증합니다.hasAuthority("SCOPE_profile")은 Access Token에profile스코프가 포함되어 있어야 해당 자원에 접근할 수 있도록 인가하는 설정입니다. // Spring Security Resource Server 설정 예시 @Configuration @EnableWebSecurity public class ResourceServerConfig { @Value("${spring.security.oauth2.resourceserver.jwt.issuer-uri}") private String issuerUri; @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(authorize -> authorize .requestMatchers("/api/public/**").permitAll() .requestMatchers("/api/admin/**").hasRole("ADMIN") // Role 기반 인가 .requestMatchers("/api/users/**").hasAuthority("SCOPE_profile") // Scope 기반 인가 .anyRequest().authenticated() ) .oauth2ResourceServer(oauth2 -> oauth2 .jwt(jwt -> jwt.decoder(JwtDecoders.fromIssuerLocation(issuerUri))) // JWT 디코더 설정 ); return http.build(); } }
Authorization Code Flow with PKCE 구현 상세 예시
가장 일반적인 웹 애플리케이션 시나리오에서 Authorization Code Flow (PKCE 포함)의 간략한 구현 흐름은 다음과 같습니다.
// 1. 클라이언트(웹 앱)가 인가 서버로 인가 요청
GET /oauth2/authorize?
response_type=code&
client_id=your-client-id&
scope=openid%20profile%20email&
redirect_uri=https://client.example.com/callback&
code_challenge=y_2hY...& // PKCE code_challenge (SHA256 해시)
code_challenge_method=S256&
state=random_state_string
// 2. 사용자가 인증 및 동의 후, 인가 서버가 클라이언트에게 인가 코드 및 state 반환
HTTP/1.1 302 Found
Location: https://client.example.com/callback?code=AUTH_CODE_XYZ&state=random_state_string
// 3. 클라이언트(웹 앱 백엔드)가 인가 코드를 접근 토큰으로 교환 요청
POST /oauth2/token
Host: authz.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
client_id=your-client-id&
client_secret=your-client-secret& // Public Client의 경우 포함하지 않음
code=AUTH_CODE_XYZ&
redirect_uri=https://client.example.com/callback&
code_verifier=y_2hY... // PKCE code_verifier (original random string)
// 4. 인가 서버가 접근 토큰, ID 토큰, 갱신 토큰 발급
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJhbG...",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "eyJhbG...",
"id_token": "eyJhbG..."
}
클라이언트는 발급받은 ID 토큰을 검증하여 사용자의 신원을 확인하고, Access Token을 사용하여 자원 서버의 보호된 자원에 접근합니다. Refresh Token은 Access Token 만료 시 새로운 토큰을 얻는 데 사용됩니다.
Image by Myriams-Fotos on Pixabay
보안 강화 및 운영 전략
인증/인가 시스템은 잠재적인 공격의 주요 대상이 되므로, 구현뿐만 아니라 운영 단계에서도 지속적인 보안 강화 노력이 필요합니다.
주요 보안 위협 및 대응
- 토큰 탈취 방지:
- HTTPS (TLS/SSL) 사용: 모든 통신은 반드시 HTTPS를 통해 암호화되어야 합니다. HTTP 사용은 토큰을 포함한 모든 민감 정보가 평문으로 노출되는 심각한 보안 취약점을 야기합니다.
- PKCE 적용: Public Client에서 Authorization Code Flow를 사용할 경우 PKCE는 필수적입니다.
- CSRF (Cross-Site Request Forgery) 방어: state 파라미터를 사용하여 인가 요청 및 콜백 과정에서 CSRF 공격을 방지합니다.
- XSS (Cross-Site Scripting) 방어: 사용자 입력값 검증, Content Security Policy (CSP) 설정 등을 통해 XSS 공격을 방어하고,
localStorage에 토큰을 저장하는 대신HttpOnly쿠키 사용을 고려합니다.
- 토큰 재사용 공격 방지:Refresh Token은 일회성 사용 정책을 적용하거나, 사용될 때마다 새로운 Refresh Token을 발급하는 Rolling Refresh Token 전략을 고려할 수 있습니다. 이는 탈취된 Refresh Token의 악용 가능성을 크게 줄여줍니다.
- 인가 서버 보안:인가 서버는 가장 중요한 보안 구성 요소입니다. 주기적인 보안 감사, 최신 보안 패치 적용, 강력한 접근 제어, 무단 접근 탐지 시스템(IDS) 구축 등이 필수적입니다. Rate Limiting을 통해 무차별 대입 공격(Brute-force attack)을 방지해야 합니다.
로깅 및 모니터링
인증/인가 시스템에서 발생하는 모든 중요한 이벤트(로그인 시도, 토큰 발급/갱신/폐기, 실패한 인증 시도 등)를 상세하게 로깅하고 모니터링해야 합니다. 이는 잠재적인 보안 위협을 조기에 탐지하고 대응하는 데 필수적입니다. 중앙 집중식 로깅 시스템과 SIEM(Security Information and Event Management) 솔루션을 활용하여 이상 징후를 분석하는 것이 효과적입니다.
정기적인 보안 감사 및 업데이트
OAuth 2.0 및 OpenID Connect 표준은 지속적으로 발전하고 있으며, 새로운 보안 취약점이 발견될 수 있습니다. 시스템을 정기적으로 감사하고, 사용 중인 라이브러리 및 프레임워크를 최신 버전으로 유지하며, 최신 보안 권고 사항을 반영하는 것이 중요합니다.
결론: 안전하고 효율적인 인증/인가 시스템의 완성
OAuth 2.0과 OpenID Connect는 현대 분산 시스템 환경에서 안전한 권한 위임과 사용자 신원 확인을 위한 필수적인 프로토콜입니다. OAuth 2.0은 클라이언트가 자원 소유자의 자원에 접근할 수 있는 권한을 얻는 인가 프레임워크의 역할을 수행하며, OIDC는 그 위에 구축되어 ID 토큰을 통해 사용자의 신원을 명확히 하는 인증 레이어를 제공합니다. 이 두 프로토콜을 올바르게 이해하고 구현함으로써, 우리는 사용자의 개인 정보를 보호하고, 서비스의 보안 수준을 높이며, 다양한 애플리케이션 간의 상호 운용성을 확보할 수 있습니다.
시스템을 설계하고 구현하는 과정에서 Grant Type의 적절한 선택, 토큰의 안전한 관리, PKCE와 같은 보안 확장 적용, 최소 권한 원칙 준수 등이 핵심적인 고려사항으로 판단됩니다. 또한, 상용 또는 오픈소스 IDaaS 솔루션을 활용하여 구현 부담을 줄이고 검증된 보안 기능을 활용하는 것이 효율적인 접근 방식입니다. 구현 이후에도 지속적인 보안 모니터링, 정기적인 감사, 최신 표준 및 보안 권고 사항 반영을 통해 시스템의 견고함을 유지하는 것이 중요합니다. 이 가이드가 여러분의 안전하고 효율적인 인증/인가 시스템 구축 여정에 실질적인 도움이 되기를 바랍니다.
OAuth 2.0 및 OpenID Connect 기반 시스템 구현과 관련하여 궁금한 점이나 추가적으로 다루었으면 하는 내용이 있다면 언제든지 댓글로 남겨주세요.