SAML vs OAuth: 핵심 차이점과 최고의 사용 사례

시작하기: 도움이 되는 비유

SAML과 OAuth의 핵심 차이점은 두 기술이 사용하는 토큰의 성격에 있습니다. SAML은 크고 공식적으로 보이는 XML 토큰을 건네줍니다. 마치 도장 찍고 공증까지 받은 문서 같은 느낌이죠. 반면 OAuth는 작은 JWT 토큰을 툭 던지며 이렇게 말합니다. “자, 이걸로 몇 시간 동안 VIP 구역에 들어갈 수 있어요. 다만 잃어버리지만은 마세요.”

이 차이를 한눈에 이해하는 데 도움이 되는 비유를 하나 들어볼게요. SAML은 마치 초호화 파티에 가는 것처럼 생각하면 됩니다. 과연 내가 입장할 수나 있을지 걱정하죠. 다행히도 친구 한 명이 문 앞에 와서 이렇게 말해줍니다. “이 사람은 내 친구예요. 멋지죠.” 그러면 주최자는 질문도 없이 당신을 들여보내고, 원하는 만큼 오래 머물 수 있습니다.

OAuth는 누군가가 자신의 차를 빌려주는 것에 더 가깝습니다. 그들은 집이나 은행 계좌나 자전거에 대한 접근 권한을 주지 않고, 그저 차만 제공합니다. 마찬가지로 OAuth는 모든 정보를 다 넘겨주지 않으면서도 특정한 작업만 수행하도록 승인합니다. 아마 “Facebook으로 로그인” 또는 “Google로 로그인”을 클릭할 때 이런 경험을 해봤을 거예요. Facebook이나 Google은 접속하려는 앱에 필요한 만큼의 정보(예: 이름과 이메일 주소)만 제공하고, 인생 전체의 이야기까지는 주지 않습니다. 특히 OAuth는 앱과 비밀번호를 공유하지 않습니다. 대신 앱에 “이 사람은 X, Y, Z를 수행할 수 있다”라고 말해주는 특별한 웹 토큰을 제공합니다.

더 깊이 알아보기: SAML (Security Assertion Markup Language)

앞서 SAML은 친구가 당신을 파티에 들여보내기 위해 보증해주는 것과 같다고 말했죠. SAML에서는 파티에 대한 접근을 요청하는 것이 아니라, 애플리케이션이나 서비스에 대한 접근을 요청합니다. 그리고 그 “친구”는 신원 제공자(identity provider)입니다(예: Google 또는 회사 내부 시스템). 이 제공자는 서비스에 대해 이미 당신을 인증했으니, 서비스가 당신의 접근 요청을 승인해야 한다고 알려줍니다.

주요 사용 사례

SAML의 가장 큰 이점은 단일 로그온(SSO)을 가능하게 하는 것입니다. 사용자는 한 번만 인증하면, 다시 로그인하거나 별도의 계정을 사용할 필요 없이 여러 시스템에 액세스할 수 있습니다.

따라서 SAML은 교육, 의료, 정부 부문의 기업처럼 SSO가 중요한 환경에 적합합니다. 서로 다른 도메인에 걸쳐 여러 애플리케이션에서 사용자를 관리하고 있으며, 사용자가 여러 번 로그인하도록 강제하지 않으면서 인증을 간소화하고 싶다면 SAML이 가장 널리 사용되는 프로토콜입니다.

SAML의 작동 방식

SAML은 세 가지 주요 구성 요소로 이루어집니다:

• 사용자 — 액세스를 시도하는 사람
• 서비스 제공자 — 사용자가 액세스하려는 애플리케이션 또는 서비스를 호스팅하는 주체
• ID 제공자 — 사용자를 인증하는 주체

이 구성 요소들은 다음과 같이 상호 작용합니다:

1. 사용자가 애플리케이션 또는 서비스에 액세스하려고 합니다.
2. 서비스 제공자는 인증을 위해 사용자를 인증 기관(identity provider)로 리다이렉트합니다.
3. 인증 기관(identity provider)은 사용자가 이미 인증을 받았는지 확인하고(아니라면 인증 단계를 수행한 뒤) 사용자를 증명하는 XML 토큰을 다시 전송합니다.
4. XML 토큰을 기반으로, 서비스 제공자는 사용자에게 앱 또는 서비스에 대한 액세스 권한을 부여합니다.

SAML의 주요 기능

• 연합형 아이덴티티(Federated identity) — 서로 다른 도메인 간에 아이덴티티를 공유할 수 있습니다
• SSO — 서로 다른 시스템 전반에서 원활한 인증을 가능하게 합니다
• 기업 사용 — 주로 B2B 환경에서 사용되며, 내부 및 제3자 애플리케이션 전반에 걸쳐 보안이 유지되는 신원 공유가 필수적인 경우에 중요합니다
• XML 기반 — 당사자 간 통신을 위해 XML에 크게 의존합니다

SAML 사용의 장점

• 계정 탈취 위험 감소 — 사용자는 한 가지 계정 정보만 필요하므로, 강력한 비밀번호를 선택할 가능성이 더 높고, 적어 두는 것과 같은 위험한 우회 방법에 의존하지 않고도 비밀번호를 기억할 수 있습니다.
• IT 운영 부담 감소 — 로그인 문제와 관련된 비밀번호 재설정 및 지원 티켓이 줄어들어 사용자와 IT 담당자 모두의 시간을 절약할 수 있습니다.
• 비밀번호 탈취 위험 감소 — 비밀번호는 사용자와 서비스 제공자 간에 전송되지 않습니다.

더 깊이 알아보기: OAuth

OAuth는 친구가 자신의 차는 사용할 수 있게 해주지만 다른 소유물은 어떤 것도 내주지 않는 것과 같다고 했습니다. 마찬가지로 OAuth는 비밀번호를 공유하지 않고도 제한된 범위의 액세스 권한을 승인합니다. 예를 들어 OAuth를 사용하면 제3자 앱이나 웹사이트가 내 Facebook 사진에 접근하도록 승인할 수 있습니다. 이때 Facebook이 사용자에 대해 저장하는 다른 정보(로그인 자격 증명 포함)는 노출되지 않습니다.

OAuth는 어떻게 작동하나요

OAuth의 주요 구성 요소는 다음과 같습니다:

• 클라이언트 — 사용자를 대신해 리소스에 대한 액세스를 요청하는 애플리케이션
• 리소스 소유자 — 요청된 데이터 또는 애플리케이션을 소유하고 있으며, 해당 리소스에 대한 액세스를 허용할 수 있는 사용자 또는 시스템
• 인증(authorization) 서버 — 사용자 동의 후 토큰을 발급하는 서버
• 리소스 서버 — 리소스를 저장하는 API 또는 서비스

프로세스는 다음과 같습니다:

1. 사용자가 리소스 소유자가 보유한 특정 사용자 데이터에 대해 클라이언트 애플리케이션의 액세스를 승인(허용)하려고 합니다.
2. 클라이언트가 적절한 권한 부여 서버에 권한(authorization)을 요청합니다.
3. 권한 부여 서버가 클라이언트를 인증한 다음, 리소스 소유자로부터 액세스에 대한 동의를 얻고, 액세스 토큰을 클라이언트에 전송합니다.
4. 클라이언트는 액세스 토큰을 사용하여 리소스 서버에 원하는 리소스에 대한 액세스를 요청합니다.

OAuth의 활용 사례

OAuth는 사용자 데이터를 제한적으로 접근해야 하는 서드파티 앱이 필요한 상황과, 소비자 대상 애플리케이션에 가장 적합합니다. 예를 들어 외부 API의 데이터에 접근해야 하는 모바일 앱을 만들고 있다면, OAuth는 사용자의 자격 증명을 손상시키지 않고도 해당 액세스 권한을 부여할 수 있는 안전하고 표준화된 방법을 제공합니다.

OAuth의 주요 기능

• 권한 부여에 집중 — 자격 증명을 공유하지 않고도 서드파티가 리소스에 접근할 수 있도록 설계됨
• API 중심 — 특히 모바일, 웹, 클라우드 애플리케이션에서 API에 대한 접근을 보안하기 위해 널리 사용됨
• 토큰 기반 —액세스 토큰(보통 JSON 형식)을 사용해 액세스를 허용하거나 거부합니다.
• 소비자 중심 — 일반적으로 Facebook, Google 같은 B2C 애플리케이션에서 사용됩니다.

OAuth를 사용하는 이점

• 침해 위험 감소 — OAuth는 제한된 시간 동안 특정 리소스에만 접근할 수 있도록 하는 토큰을 사용합니다.
• 유연성 — OAuth는 모바일 기기, 데스크톱, 웹 브라우저, IoT 기기에서 사용할 수 있습니다.
• 고객 만족도 향상 — 조직은 Google 또는 Facebook과 같은 신뢰할 수 있는 제3자 인증(권한 부여) 시스템을 사용하여 자사 리소스에 대한 액세스를 허용함으로써 고객 경험을 간소화할 수 있습니다.

비교 분석: SAML vs. OAuth

SAML과 OAuth의 공통점

• OAuth와 SAML 모두 단일 로그온(Single Sign-On)을 지원하여 사용자가 한 번 인증하면 여러 서비스에 액세스할 수 있습니다.
• 두 프로토콜 모두 여러 시스템, 애플리케이션 또는 조직 간에 신원(Identity) 정보를 공유할 수 있게 해줍니다.
• 두 프로토콜 모두 제3자 서비스와 함께 자격 증명을 공유하거나 저장할 필요가 없도록 하여 사용자 편의성과 보안을 모두 강화합니다.

SAML과 OAuth의 차이점

• OAuth는 가벼운 JSON 기반 토큰을 사용하는 반면, SAML은 장문의 XML 기반 토큰을 사용합니다.
• OAuth는 보통 소비자용 웹 및 모바일 앱에 사용되는 반면, SAML은 주로 엔터프라이즈 수준의 SSO와 아이덴티티 연동(페더레이션)에 사용됩니다.
• OAuth 토큰은 API에 대한 액세스를 승인하는 데 사용되는 반면, SAML 어설션은 시스템 간 인증을 설정하는 데 사용됩니다.

나란히 비교

프로토콜 공존

SAML과 OAuth는 인증과 인가를 모두 필요로 하는 시스템에서 함께 작동할 수 있습니다. 예를 들어 직원이 SAML을 사용해 사내 시스템에 로그인한 다음, 시스템이 OAuth 액세스 토큰을 발급하여 Microsoft Graph나 Google Drive와 같은 외부 서비스 또는 API와 상호 작용할 수 있도록 할 수 있습니다.

보안 우려 사항 및 모범 사례

토큰 탈취 및 재전송(리플레이) 공격

OAuth 토큰은 일반적으로 장기간 유효하기 때문에 악의적인 행위자에게 탈취될 위험이 있습니다. 행위자는 이를 사용해 중요 데이터나 시스템에 접근할 수 있습니다. 예를 들어 OAuth 토큰은 Man-in-the-Middle(중간자) 공격과 같은 기법을 통해 가로챌 수 있으며, 충분히 보호되지 않은 저장소에서 도난당할 수도 있습니다.

이러한 위험을 최소화하려면 조직은 수명이 짧은 액세스 토큰을 사용하고, 항상 TLS 암호화를 제공하는 HTTPS를 사용해야 합니다.

XML Signature Wrapping

XML 서명은 SAML 토큰과 같은 XML 문서에 첨부되는 디지털 서명입니다. 유효한 서명은 해당 문서가 신뢰할 수 있는 출처에서 왔으며 변조되지 않았음을 의미합니다. 공격자는 유효한 서명을 유지한 채 SAML 토큰에 악성 데이터를 주입함으로써 이 검증 메커니즘을 악용할 수 있습니다.

이러한 공격에 대응하기 위해 조직은 강력한 디지털 서명을 요구하고, SAML 토큰을 암호화하여 무결성과 기밀성을 보호할 수 있습니다.

미래의 트렌드와 발전

조직들은 비밀번호만 사용하는 기존 인증 방식에서 빠르게 벗어나, 다중 인증(multifactor authentication, MFA)과 패스키(passkeys) 같은 비밀번호 없는 옵션을 선호하고 있습니다. 더 넓게는 Zero Trust 보안 모델을 도입하고 있는데, 이는 “절대 신뢰하지 말고, 항상 확인하라”는 원칙의 필요성을 강조합니다. 또한 위협 탐지 역량을 강화하기 위해 인공지능(AI)과 머신러닝(ML)을 적극적으로 도입하고 있습니다.

결론

SAML과 OAuth는 모두 애플리케이션과 데이터에 대한 액세스를 관리하는 데 중요한 역할을 하지만, 해결하는 과제는 서로 다릅니다. SAML은 사용자의 신원을 확인하는 데 초점을 두며, 기업 환경에서 SSO에 흔히 사용됩니다. 반면 OAuth는 웹과 모바일 애플리케이션에서 API와 리소스에 안전하게 접근할 수 있도록 세분화된 비밀번호 없는 권한 부여를 위해 설계되었습니다. 두 프로토콜 모두 강력한 보안을 유지하면서도 더 매끄럽고 더 간편한 사용자 경험을 만들려는 노력을 뒷받침해 줍니다.