SAML vs. OAuth 2.0

SAML vs. OAuth 2.0

인증(Authentication)과 권한 부여(Authorization)는 현대 웹 애플리케이션과 시스템에서 핵심적인 보안 구성 요소이다. SAML(Security Assertion Markup Language)과 OAuth 2.0은 이러한 기능을 제공하는 두 가지 주요 프로토콜이지만, 설계 철학, 사용 사례 및 기술적 구현에서 상당한 차이가 있다.

기본 개념 및 역사

SAML (Security Assertion Markup Language)

SAML은 2002년 OASIS(Organization for the Advancement of Structured Information Standards)에 의해 개발된 XML 기반 개방형 표준으로, 당시 기업들이 직면한 단일 인증 문제를 해결하기 위해 설계되었다. 현재 가장 널리 사용되는 버전은 2005년에 발표된 SAML 2.0이다.

SAML의 주요 목적은 신원 공급자(Identity Provider, IdP)와 서비스 공급자(Service Provider, SP) 사이에 인증 정보를 교환할 수 있는 표준화된 방법을 제공하는 것이다. 이를 통해 사용자는 한 번 로그인하여 여러 서비스에 접근할 수 있다(SSO, Single Sign-On).

OAuth 2.0

OAuth는 원래 2007년에 Twitter와 Google의 엔지니어들에 의해 개발되었으며, 2012년에 IETF(Internet Engineering Task Force)에 의해 OAuth 2.0으로 표준화되었다.

OAuth 2.0의 주요 목적은 사용자가 자신의 자격 증명을 공유하지 않고도 타사 애플리케이션에 자신의 데이터에 대한 제한된 접근 권한을 부여할 수 있도록 하는 것이다. 이는 소셜 미디어 플랫폼이 성장하면서 발생한 ‘비밀번호 안티패턴’(여러 서비스에 동일한 비밀번호 사용) 문제를 해결하기 위해 개발되었다.

기본 아키텍처 및 작동 방식

SAML의 작동 방식

SAML은 다음과 같은 주요 구성 요소로 이루어져 있다:

1. 주체(Principal): 인증을 요청하는 사용자
2. 신원 공급자(IdP): 사용자를 인증하고 SAML 어설션을 발행하는 시스템
3. 서비스 공급자(SP): 사용자가 접근하고자 하는 애플리케이션 또는 서비스

SAML의 일반적인 인증 흐름은 다음과 같다(SP-초기화 흐름 기준):

1. 사용자가 SP에 접근을 시도한다.
2. SP는 사용자를 IdP로 리다이렉트한다(SAML 인증 요청 포함).
3. IdP는 사용자를 인증한다(이미 인증된 세션이 없는 경우).
4. IdP는 SAML 어설션(사용자 ID 및 속성 정보 포함)을 생성한다.
5. IdP는 사용자 브라우저를 SAML 어설션과 함께 SP로 다시 리다이렉트한다.
6. SP는 SAML 어설션을 검증하고 사용자에게 접근 권한을 부여한다.

OAuth 2.0의 작동 방식

OAuth 2.0은 다음과 같은 주요 구성 요소로 이루어져 있다:

1. 리소스 소유자(Resource Owner): 보호된 리소스에 대한 접근 권한을 부여하는 사용자
2. 클라이언트(Client): 리소스 소유자를 대신하여 보호된 리소스에 접근하려는 애플리케이션
3. 권한 부여 서버(Authorization Server): 리소스 소유자를 인증하고 액세스 토큰을 발행하는 서버
4. 리소스 서버(Resource Server): 보호된 리소스를 호스팅하는 서버

OAuth 2.0의 일반적인 권한 부여 흐름(권한 부여 코드 흐름)은 다음과 같다:

1. 클라이언트가 리소스 소유자에게 권한을 요청한다.
2. 리소스 소유자가 권한을 부여하면, 클라이언트는 권한 부여 코드를 받는다.
3. 클라이언트는 권한 부여 코드와 자신의 인증 정보를 권한 부여 서버에 제출한다.
4. 권한 부여 서버는 클라이언트를 인증하고 권한 부여 코드를 검증한 후, 액세스 토큰을 발행한다.
5. 클라이언트는 액세스 토큰을 사용하여 리소스 서버의 보호된 리소스에 접근한다.

주요 차이점

1. 주요 목적 및 용도

   • SAML: 주로 기업 환경에서 단일 로그인(SSO)을 구현하기 위해 설계되었다. 사용자가 여러 애플리케이션에 한 번만 로그인할 수 있도록 하는 인증(Authentication)에 중점을 둔다.
   • OAuth 2.0: 주로 타사 애플리케이션이 사용자 데이터에 접근할 수 있도록 권한을 부여하는 데 중점을 둔다. 즉, 인증보다는 권한 부여(Authorization)에 초점을 맞춘다.

2. 기술적 구현

   • SAML: XML 기반 프로토콜로, 메시지 형식이 복잡하고 크기가 크다. XML 서명과 암호화를 사용하여 메시지 보안을 제공한다.
   • OAuth 2.0: 경량화된 JSON/HTTP 기반 프로토콜로, 구현이 상대적으로 간단하다. TLS/SSL을 통한 전송 보안에 의존한다.

3. 토큰 및 데이터 형식

   • SAML: SAML 어설션은 XML 문서로, 서명 및 암호화될 수 있다. 어설션에는 인증, 속성 및 권한 부여 결정 정보가 포함될 수 있다.
   • OAuth 2.0: 액세스 토큰은 일반적으로 불투명한 문자열이며, 리프레시 토큰을 통해 새로운 액세스 토큰을 획득할 수 있다. JWT(JSON Web Token)를 사용하여 토큰에 클레임을 포함할 수도 있다.

4. 클라이언트 유형 및 애플리케이션 지원

   • SAML: 주로 웹 애플리케이션에 초점을 맞추고 있으며, 브라우저 리다이렉션에 의존한다. 모바일 또는 단일 페이지 애플리케이션(SPA)에서는 제한적으로 사용된다.
   • OAuth 2.0: 다양한 클라이언트 유형(웹, 모바일, 데스크톱, IoT 장치 등)을 지원하도록 설계되었다. 다양한 애플리케이션 유형에 맞는 여러 가지 권한 부여 흐름을 제공한다.

5. 확장성 및 적응성

   • SAML: 엄격한 XML 스키마를 따르며, 확장이 복잡할 수 있다. 주로 대규모 엔터프라이즈 환경에서 사용된다.
   • OAuth 2.0: 더 모듈화되고 확장 가능한 프레임워크로 설계되었다. OpenID Connect와 같은 확장을 통해 인증 기능을 추가할 수 있다.

6. 수명 주기 및 세션 관리

   • SAML: 세션 관리에 대한 내장 지원을 제공한다. 단일 로그아웃(SLO) 기능을 통해 여러 서비스에서 동시에 로그아웃할 수 있다.
   • OAuth 2.0: 기본적으로 세션 관리 기능이 없으며, 토큰 만료 시간을 통해 간접적으로 관리된다. 세션 관리는 일반적으로 추가 메커니즘을 통해 구현해야 한다.

7. 보안 특성

   • SAML: XML 서명과 암호화를 통해 강력한 메시지 수준 보안을 제공한다. 기업 환경에서 높은 수준의 보안을 제공하도록 설계되었다.
   • OAuth 2.0: TLS/SSL을 통한 전송 수준 보안에 의존한다. PKCE(Proof Key for Code Exchange)와 같은 추가 보안 메커니즘을 통해 특정 위협을 완화할 수 있다.

사용 사례 비교

SAML에 적합한 사용 사례

1. 기업 단일 로그인(SSO): 직원들이 한 번의 로그인으로 여러 내부 시스템에 접근할 수 있다.
2. B2B 연합(Federation): 비즈니스 파트너 간의 신원 정보 교환을 용이하게 한다.
3. 클라우드 서비스 통합: 기업 자격 증명으로 SaaS 애플리케이션(Salesforce, Office 365 등)에 접근한다.
4. 고도의 규제를 받는 산업: 의료, 금융 등에서 강력한 보안 및 감사 요구 사항을 충족한다.

OAuth 2.0에 적합한 사용 사례

1. API 접근 제어: 타사 애플리케이션이 사용자 데이터에 안전하게 접근할 수 있도록 한다.
2. 소셜 로그인: Facebook, Google 등의 계정을 사용하여 다른 서비스에 로그인한다.
3. 모바일 애플리케이션: 네이티브 모바일 앱에서 서버 API에 대한 권한 부여를 처리한다.
4. 마이크로서비스 아키텍처: 서비스 간 통신에서 권한 부여를 관리한다.
5. IoT 장치: 제한된 리소스를 가진 장치에서 API 접근을 관리한다.

구현 복잡성

1. SAML 구현의 복잡성
   SAML 구현은 일반적으로 다음과 같은 이유로 더 복잡하다:
   • XML 처리 및 XML 디지털 서명에 대한 지식이 필요하다.
   • 메타데이터 교환 및 관리가 복잡할 수 있다.
   • 디버깅이 어려울 수 있으며, 오류 메시지가 명확하지 않을 수 있다.
   • 초기 설정 및 구성이 복잡하다.
2. OAuth 2.0 구현의 복잡성
   OAuth 2.0은 상대적으로 구현이 더 간단하지만, 여전히 몇 가지 도전 과제가 있다:
   • 다양한 권한 부여 흐름을 이해하고 적절히 선택해야 한다.
   • 토큰 관리 및 검증이 필요하다.
   • CSRF 공격 및 기타 보안 위협에 대한 보호 메커니즘을 구현해야 한다.
   • 리다이렉션 URI 관리 및 상태 파라미터 처리가 필요하다.

최신 동향 및 미래 전망

SAML의 현재 상태

SAML은 성숙한 기술로, 많은 기업에서 여전히 광범위하게 사용되고 있다. 특히 대규모 기업 환경과 전통적인 웹 애플리케이션에서 강점을 보인다. 그러나 모바일 및 최신 웹 아키텍처에서는 사용이 감소하는 추세이다.

OAuth 2.0의 진화

OAuth 2.0은 계속해서 발전하고 확장되고 있다. OpenID Connect(OIDC)와의 통합을 통해 인증 기능이 강화되었으며, OAuth 2.1이 개발 중이다. OAuth 2.0은 API 경제와 마이크로서비스 아키텍처가 성장함에 따라 더욱 중요해지고 있다.

두 프로토콜의 사용 전망

현재 많은 조직에서는 사용 사례에 따라 SAML과 OAuth를 함께 사용하고 있다:

• SAML은 내부 기업 SSO 및 B2B 시나리오에서 계속 사용된다.
• OAuth 2.0과 OIDC는 새로운 API 중심 개발, 모바일 앱 및 최신 웹 애플리케이션에 선호된다.
• 장기적으로는 OAuth 2.0/OIDC로의 점진적인 이동이 예상되지만, SAML은 특히 레거시 시스템 및 특정 엔터프라이즈 사용 사례에서 계속해서 중요한 역할을 할 것이다.

SAML과 OAuth 2.0 비교

용어 정리

참고 및 출처