안전한 인증/인가 시스템 구축: OAuth 2.0과 OpenID Connect 심층 분석

복잡한 현대 웹 서비스 환경에서 OAuth 2.0 및 OpenID Connect를 활용한 안전하고 효율적인 인증/인가 시스템 설계의 핵심 원리와 보안 고려사항을 심층 분석합니다.

오늘날 수많은 웹 서비스와 모바일 애플리케이션은 사용자의 편리성과 서비스 간 연동을 위해 외부 서비스의 데이터에 접근하거나, 단일 계정으로 여러 서비스에 로그인하는 기능을 제공합니다. 이 과정에서 사용자 신원 확인(인증)과 특정 리소스 접근 권한 부여(인가)는 가장 중요한 보안 과제 중 하나로 손꼽힙니다. 복잡한 인증/인가 로직을 직접 구현하는 것은 높은 비용과 보안 취약점을 야기할 수 있기에, 업계 표준 프로토콜을 활용하는 것이 일반적입니다. 그렇다면 수많은 기술 중에서 OAuth 2.0과 OpenID Connect는 왜 현대 인증/인가 시스템 설계의 핵심으로 자리 잡았을까요? 그리고 이 두 기술을 기반으로 시스템을 설계할 때 반드시 고려해야 할 보안 사항은 무엇일까요? 이 글에서는 두 프로토콜의 작동 원리, 핵심 차이점, 그리고 안전한 시스템 구축을 위한 보안 전략을 심층적으로 분석합니다.

📑 목차

• OAuth 2.0: 인가(Authorization)의 표준
• OAuth 2.0의 핵심 구성 요소
• OAuth 2.0의 주요 흐름: 권한 부여 코드(Authorization Code Grant)
• OpenID Connect: 인증(Authentication) 계층 추가
• OpenID Connect의 핵심 요소
• 두 기술의 핵심 차이점과 연동 전략
• 인증/인가 시스템 설계 시 보안 고려사항
• 토큰 관리의 중요성
• 클라이언트 보안
• 공격 방어 메커니즘
• 실제 시스템 구현 시 주의사항 및 모범 사례
• 결론: 안전하고 유연한 시스템을 위한 선택

Image by andri333 on Pixabay

OAuth 2.0: 인가(Authorization)의 표준

OAuth 2.0은 권한 위임(Delegated Authorization)을 위한 프레임워크로, 한 서비스가 사용자의 명시적인 동의 하에 다른 서비스의 리소스에 접근할 수 있는 권한을 얻는 과정을 표준화합니다. 이는 사용자가 자신의 아이디와 비밀번호를 제3의 서비스에 직접 제공하지 않고도 안전하게 리소스 접근 권한을 위임할 수 있도록 돕습니다. OAuth 2.0은 인증(Authentication)보다는 인가(Authorization)에 초점을 맞추고 있으며, 사용자의 신원을 확인하는 기능은 기본적으로 포함되어 있지 않습니다.

OAuth 2.0의 핵심 구성 요소

• 리소스 소유자(Resource Owner): 보호된 리소스에 대한 접근 권한을 가진 사용자입니다. 애플리케이션에 자신의 데이터에 대한 접근을 허용합니다.
• 클라이언트(Client): 리소스 소유자로부터 권한을 위임받아 리소스 서버에 접근하려는 애플리케이션입니다. 예를 들어, 사용자의 Google 드라이브 파일에 접근하려는 사진 편집 앱 등이 해당됩니다.
• 권한 서버(Authorization Server): 리소스 소유자의 인증을 수행하고, 클라이언트에게 액세스 토큰(Access Token)을 발급합니다.
• 리소스 서버(Resource Server): 보호된 리소스를 호스팅하며, 유효한 액세스 토큰을 통해 리소스에 대한 접근을 허용합니다.

OAuth 2.0의 주요 흐름: 권한 부여 코드(Authorization Code Grant)

가장 널리 사용되고 보안성이 높은 권한 부여 코드(Authorization Code Grant) 흐름은 다음과 같은 단계로 진행됩니다.

1. 클라이언트는 리소스 소유자를 권한 서버의 인가 엔드포인트(/authorize)로 리다이렉트합니다. 이때 클라이언트 ID, 요청 스코프, 리다이렉트 URI, CSRF 방지를 위한 `state` 파라미터 등을 포함합니다.
2. 리소스 소유자는 권한 서버에서 자신의 신원을 인증하고, 클라이언트가 요청한 권한에 동의할지 결정합니다.
3. 리소스 소유자가 동의하면, 권한 서버는 클라이언트의 리다이렉트 URI로 권한 부여 코드(Authorization Code)와 `state` 파라미터를 함께 리다이렉트합니다.
4. 클라이언트는 이 권한 부여 코드를 가지고 권한 서버의 토큰 엔드포인트(/token)에 POST 요청을 보냅니다. 이때 클라이언트 ID, 클라이언트 시크릿, 리다이렉트 URI, 권한 부여 코드를 포함합니다.
5. 권한 서버는 받은 정보를 검증하고, 유효한 경우 액세스 토큰과 리프레시 토큰(Refresh Token)을 클라이언트에게 발급합니다.
6. 클라이언트는 발급받은 액세스 토큰을 사용하여 리소스 서버에 보호된 리소스 요청을 보냅니다.
7. 리소스 서버는 액세스 토큰의 유효성을 검증하고, 유효하면 요청된 리소스를 클라이언트에게 제공합니다.

특히, 모바일 앱이나 SPA(Single Page Application)와 같이 클라이언트 시크릿(Client Secret)을 안전하게 보관하기 어려운 환경에서는 PKCE(Proof Key for Code Exchange) 확장 기능을 사용하여 권한 부여 코드 가로채기 공격을 방지하는 것이 강력히 권장됩니다. PKCE는 클라이언트가 권한 부여 요청 시 코드 챌린지를 생성하고, 토큰 요청 시 코드 베리파이어를 제공하여 중간자 공격을 방어합니다.

# 인가 요청 예시 (클라이언트 -> 권한 서버)
GET https://authorization-server.com/authorize?
    response_type=code&
    client_id=YOUR_CLIENT_ID&
    scope=read_profile%20write_data&
    redirect_uri=https://client-app.com/callback&
    state=someRandomStringForCSRFProtection&
    code_challenge=CODE_CHALLENGE_FOR_PKCE&
    code_challenge_method=S256

# 토큰 요청 예시 (클라이언트 -> 권한 서버)
POST https://authorization-server.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTHORIZATION_CODE_RECEIVED&
redirect_uri=https://client-app.com/callback&
client_id=YOUR_CLIENT_ID&
client_secret=YOUR_CLIENT_SECRET&
code_verifier=CODE_VERIFIER_FOR_PKCE

OpenID Connect: 인증(Authentication) 계층 추가

OpenID Connect(OIDC)는 OAuth 2.0 프레임워크 위에 구축된 단순한 아이덴티티 레이어입니다. OAuth 2.0이 인가에 중점을 둔 반면, OIDC는 사용자의 신원을 확인(인증)하고, 해당 사용자에 대한 기본 프로필 정보를 클라이언트에게 안전하게 제공하는 것을 목표로 합니다. 즉, "누구(Who)인가"에 대한 질문에 답하는 역할을 수행합니다.

OpenID Connect의 핵심 요소

OIDC는 OAuth 2.0의 흐름을 따르면서 다음과 같은 추가적인 기능을 제공합니다.

• ID 토큰(ID Token): OAuth 2.0의 액세스 토큰과 함께 발급되는 JWT(JSON Web Token) 형식의 토큰입니다. 사용자 인증 정보를 포함하며, 클라이언트는 이 ID 토큰을 파싱하여 사용자의 신원을 확인하고 기본 프로필 정보(예: 사용자 ID, 이름, 이메일 등)를 얻을 수 있습니다. ID 토큰은 주로 클라이언트 측에서 사용자의 신원을 검증하는 데 사용됩니다.
• UserInfo 엔드포인트(UserInfo Endpoint): 액세스 토큰을 사용하여 추가적인 사용자 프로필 정보를 요청할 수 있는 표준화된 API 엔드포인트입니다. ID 토큰에 포함된 정보보다 더 상세한 사용자 정보를 얻을 때 활용됩니다.
• Scope 'openid': OIDC를 사용하겠다는 의도를 나타내는 필수 스코프입니다.
• `nonce` 파라미터: 리플레이 공격(Replay Attack)을 방지하기 위해 클라이언트가 인가 요청 시 생성하여 전달하는 임의의 문자열입니다. ID 토큰에도 이 `nonce` 값이 포함되어 클라이언트는 이를 검증하여 토큰의 유효성을 확인합니다.

OIDC 흐름은 OAuth 2.0의 권한 부여 코드 흐름과 거의 동일하지만, 인가 서버가 액세스 토큰과 함께 ID 토큰을 발급한다는 점이 가장 큰 차이점입니다. 클라이언트는 이 ID 토큰을 받아 유효성을 검증함으로써 사용자의 인증 상태를 확인합니다.

# ID 토큰 (JWT) 예시 - 디코딩 시 페이로드
{
  "iss": "https://accounts.google.com",  # 발급자 (Issuer)
  "sub": "101234567890123456789",         # 사용자 고유 식별자 (Subject)
  "aud": "YOUR_CLIENT_ID",              # 대상 클라이언트 ID (Audience)
  "exp": 1678886400,                    # 만료 시간 (Expiration Time)
  "iat": 1678882800,                    # 발급 시간 (Issued At)
  "auth_time": 1678882700,              # 인증 시간
  "nonce": "someRandomNonceValue",      # 리플레이 공격 방지
  "name": "홍길동",
  "email": "gildong.hong@example.com",
  "picture": "https://example.com/profile/gildong.jpg"
}

두 기술의 핵심 차이점과 연동 전략

OAuth 2.0과 OpenID Connect는 밀접하게 연관되어 있지만, 근본적인 목적과 역할에서 차이를 보입니다. 이들을 명확히 이해하고 적절히 연동하는 것이 안전하고 효율적인 시스템 설계의 핵심입니다.

특징	OAuth 2.0	OpenID Connect
목적	인가(Authorization): 리소스 소유자의 리소스에 대한 접근 권한 위임	인증(Authentication): 사용자 신원 확인 및 기본 프로필 정보 제공
역할	권한 서버가 클라이언트에게 액세스 토큰 발급	인증 서버가 클라이언트에게 ID 토큰(JWT) 발급
제공 정보	특정 리소스에 대한 접근 권한	사용자의 신원(Who) 및 기본 프로필 정보
기반 기술	독립적인 프레임워크	OAuth 2.0 위에 구축된 아이덴티티 레이어
주요 토큰	액세스 토큰 (Access Token)	ID 토큰 (ID Token), 액세스 토큰
사용 사례	타사 앱이 Google 드라이브 파일 접근, 특정 API 호출 권한 획득	Google/Facebook 계정으로 다른 웹사이트 로그인 (싱글 사인온, SSO)

이 두 기술은 상호 보완적으로 사용됩니다. 예를 들어, 사용자가 Google 계정으로 웹 서비스에 로그인하려고 할 때:

1. 클라이언트(웹 서비스)는 OIDC를 사용하여 Google 인증 서버에 사용자의 신원 확인을 요청합니다 (여기서 OIDC는 OAuth 2.0 흐름을 사용합니다).
2. Google 인증 서버는 사용자를 인증하고, 클라이언트에게 ID 토큰(사용자 신원 정보)과 액세스 토큰(Google API 접근 권한)을 발급합니다.
3. 클라이언트는 ID 토큰을 검증하여 사용자의 신원을 확인하고 로그인 처리를 완료합니다.
4. 이후 클라이언트는 발급받은 액세스 토큰을 사용하여 사용자의 Google 캘린더나 연락처 등 Google의 리소스 서버에 접근할 수 있습니다.

이러한 연동을 통해 클라이언트는 사용자의 신원을 안전하게 확인하고, 동시에 필요한 경우 사용자 데이터에 대한 접근 권한까지 확보할 수 있게 됩니다.

Image by Myriams-Fotos on Pixabay

인증/인가 시스템 설계 시 보안 고려사항

OAuth 2.0과 OpenID Connect는 강력한 보안 기능을 제공하지만, 이를 잘못 구현하거나 특정 공격 벡터를 간과하면 심각한 보안 취약점으로 이어질 수 있습니다. 시스템 설계 및 구현 단계에서 다음 사항들을 반드시 고려해야 합니다.

토큰 관리의 중요성

• 액세스 토큰 유효 기간 최소화: 액세스 토큰은 보호된 리소스에 직접 접근하는 데 사용되므로, 탈취 시 피해를 최소화하기 위해 유효 기간을 짧게 설정해야 합니다. 일반적으로 몇 분에서 길어도 1시간 이내로 설정하고, 만료 시 리프레시 토큰을 사용하여 새로운 액세스 토큰을 발급받도록 합니다.
• 리프레시 토큰 보안 강화: 리프레시 토큰은 액세스 토큰보다 긴 유효 기간을 가지며, 새로운 액세스 토큰을 발급받는 데 사용되므로 매우 민감합니다.
  • 안전한 저장: 웹 애플리케이션에서는 HTTP-only, Secure 속성이 설정된 쿠키에 저장하는 것이 일반적입니다. JavaScript 접근을 막아 XSS 공격으로부터 보호하고, HTTPS를 통해서만 전송되도록 합니다. 모바일 앱에서는 키체인(Keychain)이나 안드로이드 키스토어(Keystore)와 같은 보안 저장소를 사용해야 합니다.
  • 일회성 사용 및 회전(Rotation): 리프레시 토큰이 사용될 때마다 새로운 리프레시 토큰을 발급하고 이전 토큰을 무효화하는 리프레시 토큰 회전 전략을 적용하면, 탈취된 토큰의 재사용을 어렵게 만들 수 있습니다.
  • 폐기(Revocation) 기능: 사용자가 로그아웃하거나 계정 정보가 변경될 경우, 발급된 모든 리프레시 토큰을 즉시 폐기할 수 있는 메커니즘을 구현해야 합니다.
• ID 토큰 검증: 클라이언트는 ID 토큰을 받은 후 반드시 다음과 같은 검증 절차를 거쳐야 합니다.
  • 서명 검증: 토큰이 변조되지 않았는지 발급자의 공개 키로 서명을 검증합니다.
  • 발급자(iss) 확인: 토큰을 발급한 권한 서버가 예상하는 서버인지 확인합니다.
  • 대상(aud) 확인: 토큰의 대상이 현재 클라이언트 ID와 일치하는지 확인합니다.
  • 만료 시간(exp) 확인: 토큰이 유효한지 확인합니다.
  • `nonce` 값 확인 (OIDC): 인가 요청 시 보낸 `nonce` 값과 ID 토큰의 `nonce` 값이 일치하는지 확인하여 리플레이 공격을 방지합니다.

클라이언트 보안

• 클라이언트 시크릿 보호: 백엔드 서버에서 실행되는 클라이언트(예: 웹 애플리케이션의 서버 측)의 경우, 클라이언트 시크릿은 절대로 외부에 노출되어서는 안 됩니다. 환경 변수, 보안 설정 파일 또는 키 관리 시스템(KMS)을 사용하여 안전하게 보관해야 합니다. SPA나 모바일 앱과 같이 클라이언트 시크릿을 안전하게 보관할 수 없는 퍼블릭 클라이언트(Public Client)는 클라이언트 시크릿을 사용하지 않고 PKCE를 반드시 적용해야 합니다.
• 리다이렉트 URI 엄격한 검증: 권한 서버에 등록된 리다이렉트 URI는 매우 정확하고 구체적이어야 합니다. 와일드카드나 광범위한 URI 패턴은 오픈 리다이렉터(Open Redirector) 취약점을 유발하여 공격자가 사용자를 악의적인 사이트로 유도할 수 있습니다. 예를 들어, `https://client.com/callback`과 같이 특정 경로까지 명시하는 것이 좋습니다.
• PKCE(Proof Key for Code Exchange) 필수 적용: SPA, 모바일 앱 등 퍼블릭 클라이언트에서는 PKCE를 사용하여 권한 부여 코드 가로채기 공격을 방지해야 합니다. 이는 권한 부여 코드가 탈취되더라도 공격자가 액세스 토큰을 얻는 것을 막아줍니다.

공격 방어 메커니즘

• CSRF(Cross-Site Request Forgery) 방어: `state` 파라미터: OAuth 2.0의 인가 요청 시 클라이언트는 임의의 난수인 `state` 파라미터를 생성하여 권한 서버로 보냅니다. 권한 서버는 이 값을 다시 클라이언트의 리다이렉트 URI로 돌려보내며, 클라이언트는 자신이 보냈던 `state` 값과 일치하는지 검증해야 합니다. 이를 통해 공격자가 생성한 가짜 요청에 대한 응답을 클라이언트가 수락하는 것을 방지할 수 있습니다.
• 리플레이 공격(Replay Attack) 방어: `nonce` 파라미터 (OIDC): OIDC에서는 CSRF 방지 목적의 `state` 외에 추가적으로 `nonce` 파라미터를 사용하여 리플레이 공격을 방어합니다. 클라이언트가 인가 요청 시 `nonce` 값을 보내면, ID 토큰에도 동일한 `nonce` 값이 포함되어 발급됩니다. 클라이언트는 ID 토큰의 `nonce`가 자신이 보낸 값과 일치하는지 확인하여, 이전에 사용된 ID 토큰을 재사용하는 공격을 막을 수 있습니다.
• TLS/HTTPS 필수 적용: 모든 OAuth 2.0 및 OpenID Connect 통신(인가 서버, 토큰 서버, 리소스 서버와 클라이언트 간)은 반드시 TLS/HTTPS를 통해 암호화되어야 합니다. 평문 통신은 토큰, 코드, 클라이언트 시크릿 등 민감한 정보가 중간에 탈취될 위험을 크게 높입니다.
• Scope 최소 권한 원칙: 클라이언트는 필요한 최소한의 권한(Scope)만을 요청해야 합니다. 예를 들어, 사용자 프로필 정보만 필요하다면 이메일 접근 권한까지 요청해서는 안 됩니다. 이는 잠재적인 피해 범위를 줄이고 사용자 개인 정보 보호에 기여합니다.
• 오픈 리다이렉터 취약점 방지: 권한 서버가 리다이렉트 URI를 검증할 때, 등록된 URI 목록에 대해서만 엄격하게 일치하는지 확인해야 합니다. 임의의 URL로 리다이렉트되는 것을 허용하면 공격자가 피싱 사이트로 사용자를 유도할 수 있습니다.

Image by LoboStudioHamburg on Pixabay

실제 시스템 구현 시 주의사항 및 모범 사례

이론적인 이해를 넘어 실제 시스템을 구현할 때는 다음과 같은 실용적인 고려사항들이 중요합니다.

• 표준 라이브러리 및 SDK 활용: 직접 구현하기보다는 검증된 OAuth 2.0/OpenID Connect 라이브러리나 SDK(예: Spring Security OAuth, Auth0 SDK, Keycloak Adapter)를 사용하는 것이 좋습니다. 이들은 대부분의 보안 고려사항을 내장하고 있어 구현 오류로 인한 취약점을 줄일 수 있습니다.
• 보안 감사 및 침투 테스트: 시스템 배포 전 반드시 보안 감사(Security Audit)와 침투 테스트(Penetration Testing)를 수행하여 잠재적인 취약점을 발견하고 개선해야 합니다.
• 모니터링 및 로깅: 인증/인가 관련 모든 이벤트를 상세히 로깅하고 모니터링해야 합니다. 비정상적인 로그인 시도, 토큰 발급 실패, 권한 오류 등을 실시간으로 감지하고 대응할 수 있도록 시스템을 구축합니다.
• 속도 제한(Rate Limiting): 토큰 엔드포인트에 대한 요청에 속도 제한을 적용하여 무차별 대입 공격(Brute-force attack)이나 서비스 거부(DoS) 공격을 방지합니다.
• 사용자 동의(Consent) 관리: 사용자가 어떤 권한을 어떤 클라이언트에게 부여했는지 명확하게 표시하고, 언제든지 동의를 철회할 수 있는 기능을 제공해야 합니다.
• 에러 메시지 최소화: 에러 발생 시 사용자에게 불필요하거나 민감한 정보를 노출하지 않도록 일반적인 에러 메시지를 제공해야 합니다. 상세한 에러 정보는 공격자에게 유용한 힌트를 제공할 수 있습니다.

결론: 안전하고 유연한 시스템을 위한 선택

OAuth 2.0과 OpenID Connect는 현대 웹 및 모바일 환경에서 인증과 인가를 구현하는 데 있어 필수적인 표준으로 자리 잡았습니다. OAuth 2.0은 리소스 소유자의 리소스에 대한 안전한 접근 권한 위임을, OpenID Connect는 그 위에 사용자 신원 확인 계층을 추가하여 편리하고 안전한 싱글 사인온(SSO) 환경을 가능하게 합니다.

그러나 이 두 프로토콜을 성공적으로 활용하고 잠재적인 위험으로부터 시스템을 보호하기 위해서는 단순히 표준을 따르는 것을 넘어, 각 구성 요소의 작동 방식과 발생 가능한 보안 위협에 대한 깊이 있는 이해가 필수적입니다. 토큰 관리, 클라이언트 보안, 그리고 다양한 공격 방어 메커니즘에 대한 철저한 고려 없이는 아무리 견고한 표준이라도 취약점으로 전락할 수 있습니다. 따라서 시스템 설계자는 최신 보안 권고 사항을 지속적으로 학습하고, 검증된 구현 방식을 채택하며, 정기적인 보안 점검을 통해 안전하고 유연하며 확장 가능한 인증/인가 시스템을 구축해야 할 것입니다.

이 글에 대한 여러분의 생각이나 추가적인 보안 팁이 있다면 댓글로 공유해주세요. 함께 더 안전한 개발 문화를 만들어나가는 데 기여할 수 있습니다!

📌 함께 읽으면 좋은 글

• [보안] 소프트웨어 공급망 보안: 의존성 관리, 코드 서명, SBOM 활용 취약점 방어 전략
• [개발 도구] API 개발 생산성 극대화: Postman, Insomnia, Hoppscotch 완벽 비교 가이드
• [AI 머신러닝] LLM 서비스 배포 및 최적화 전략: 비용 효율적인 추론 환경 구축과 성능 관리

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.