OAuth 2.0 대 SAML: API 보안 주장

API (응용 프로그램 프로그래밍 인터페이스) 보안은 대중 사용을 위한 운영 API에 매우 중요합니다. API가 주로 서로 다른 응용 프로그램 간의 통신을 촉진하는 중개자로 사용되는 만큼, 두 당사자 간에 교환되는 데이터가 기밀로 유지될 수 있도록 충분한 보안을 가져야 합니다.

OAuth 2.0 및 SAML은 개발자가 사용할 수 있는 두 가지 주요 권한 부여 프레임워크입니다. 따라서 이 글에서는 OAuth 2.0과 SAML에 대한 세부 사항을 다룰 것입니다. 세부설명으로 들어가기 전에 OAuth 2.0과 SAML에 대한 간단한 요약이 있을 것입니다.

OAuth 2.0이란 무엇인가요?

OAuth 2.0은 응용 프로그램 프로그래밍 인터페이스(API)를 위해 특별히 설계된 산업 표준 권한 부여 프레임워크입니다. 이는 자원 소유자(일반적으로 사용자)가 자신의 실제 자격 증명을 공개하지 않고 제3자 응용 프로그램(클라이언트)에 서비스 내 정보에 대한 관리된 접근을 허용할 수 있는 안전한 방법을 촉진합니다.

OAuth 2.0의 종합적 분석

OAuth 2.0은 API를 위한 산업 표준 권한 부여 프레임워크로 안전한 위임 접근을 중심으로 구성됩니다. 이 프레임워크의 구성 요소, 작업 과정 및 보안 고려 사항을 탐구해 보겠습니다.

OAuth 2.0의 주요 역할

• 자원 소유자(RO): 엑세스되는 자원을 제어하는 개인(일반적으로 사용자). 이는 그들의 사진, 이메일 또는 서비스에 저장된 다른 데이터를 포함할 수 있습니다.
• 자원 서버(RS): 보호된 자원을 저장하고 클라이언트가 제공한 접근 토큰을 검증하는 서버입니다.
• 클라이언트(제3자 애플리케이션): RO를 대신해 자원에 접근을 요청하는 애플리케이션입니다. 이는 사진 편집 앱, 피트니스 추적기 또는 사용자 데이터가 필요한 기타 서비스일 수 있습니다.
• 권한 부여 서버(AS): RO의 권한을 검증한 후 접근 토큰을 발급하는 서버입니다. RO, 클라이언트 및 RS 간의 신뢰할 수 있는 중개자 역할을 합니다.

OAuth 2.0 권한 부여 흐름

OAuth 2.0은 다양한 응용 프로그램 유형 및 보안 요구에 맞춘 여러 권한 부여 흐름을 정의합니다. 주요 흐름은 다음과 같습니다:

• 권한 부여 코드 부여: 이 흐름은 웹 애플리케이션에 일반적으로 사용됩니다. 클라이언트는 RO를 AS로 리디렉션하여 접근 권한을 부여하거나 거부합니다. 부여되면, AS는 클라이언트에 권한 부여 코드를 발급합니다. 클라이언트는 이 코드를 AS와 교환하여 접근 토큰을 받습니다. 이 두 단계 과정은 권한 부여 코드를 단기적이고 기밀로 유지하여 보안을 강화합니다.
• 암시적 부여: 이 흐름은 공개 클라이언트 애플리케이션(예: 비밀 저장소가 제한된 모바일 앱)에 적합합니다. AS는 RO의 권한 부여 후 클라이언트에 직접 접근 토큰을 반환합니다. 편리하긴 하지만, 이 흐름은 클라이언트 애플리케이션 내에서 접근 토큰 노출로 인한 보안 위험이 있습니다.
• 자원 소유자 비밀번호 부여: 이 흐름은 일반적으로 클라이언트가 RO 자격 증명에 대한 안전한 저장소를 갖는 서버 측 애플리케이션에서 사용됩니다. RO는 자신의 자격 증명을 클라이언트에 직접 제공하며, 클라이언트는 이를 사용하여 AS로부터 접근 토큰을 얻습니다. 자격 증명의 노출로 인해, 이 흐름은 신중하게 사용해야 합니다.
• 클라이언트 자격 부여: 이 흐름은 클라이언트가 미리 구성된 자격 증명을 갖춘 기계 대 기계 권한 부여에 사용됩니다. 클라이언트는 이러한 자격 증명을 사용하여 특정 자원에 접근하기 위해 AS로부터 직접 접근 토큰을 얻습니다.

이들은 일반적인 흐름 중 일부에 불과하며, 선택은 애플리케이션 유형, 보안 요구 사항 및 사용자 경험 고려 사항과 같은 요소에 따라 다릅니다.

OAuth 2.0 토큰

• 접근 토큰: 성공적인 권한 부여 후 AS가 클라이언트에 발급하는 단기 자격 증명입니다. RO를 대신하여 RS의 특정 자원에 접근할 수 있는 권한을 부여합니다. 접근 토큰은 종종 불투명하게 설계되어 민감한 정보를 포함하지 않습니다.
• 갱신 토큰(선택 사항): 추가 RO 상호 작용 없이 새로운 접근 토큰을 얻는 데 사용되는 장기 자격 증명(종종 더 엄격한 보안 조치가 적용됨)입니다. 이는 접근을 유지해야 하는 장기간 실행되는 애플리케이션에 유용합니다.

OAuth 2.0 보안 고려 사항

• 제한된 범위: 접근 토큰은 일반적으로 특정 범위 내에서 부여되어 클라이언트가 접근할 수 있는 자원을 제한합니다.
• 단기 접근 토큰: 접근 토큰은 제한된 수명을 가지며, 손상될 경우의 취약성 윈도우를 최소화합니다.
• 갱신 토큰 보안: 갱신 토큰은 장기성 때문에 신중한 처리 필요. 안전한 저장소 및 적절한 무효화 메커니즘이 필수적입니다.
• HTTPS 통신: OAuth 흐름에 관련된 당사자 간 모든 통신은 도청 및 중간자 공격을 방지하기 위해 HTTPS를 사용하여 암호화해야 합니다.

OAuth 2.0의 장점

• 개선된 보안: 클라이언트가 RO 자격 증명을 저장할 필요를 없애 데이터 유출 위험을 줄입니다.
• 세부적인 접근 제어: 클라이언트가 접근할 수 있는 자원에 대한 세밀한 제어를 제공합니다.
• 표준화된 프레임워크: 명확하게 정의된 권한 부여 메커니즘을 제공하여 애플리케이션 개발을 간소화합니다.
• 유연성: 다양한 권한 부여 흐름을 통해 다양한 애플리케이션 유형을 지원합니다.

SAML이란 무엇인가요?

보안 단언 마크업 언어(Security Assertion Markup Language, SAML)는 보안 도메인 간의 인증 및 권한 부여 데이터를 교환하기 위한 XML 기반 표준입니다. 이는 웹 애플리케이션 전반에 걸쳐 안전한 단일 로그인(SSO) 프레임워크를 촉진하여 사용자가 한 번 인증을 받고 자격 증명을 다시 입력하지 않고도 여러 자원에 접근할 수 있도록 합니다.

SAML의 종합적 분석

보안 단언 마크업 언어(SAML)는 웹 단일 로그인(SSO) 및 접근 제어에서 중요한 역할을 합니다. 이 심층 분석에서는 SAML의 핵심 개념, 기능, 보안 측면 및 실용적 고려 사항을 살펴봅니다.

SAML의 핵심 기능

SAML은 두 개체 간에 설정된 신뢰를 기반으로 작동합니다:

• 신원 공급자(IdP): 신뢰할 수 있는 인증 기관으로 작용합니다. 사용자 자격 증명을 검증하고 사용자의 신원 속성(예: 이름, 이메일 주소, 그룹 구성원)에 대한 단언을 발급합니다. 이를 회사의 안전한 로그인 포털이라고 생각할 수 있습니다.
• 서비스 공급자(SP): 사용자의 인증 및 권한 부여 결정을 위해 IdP에 의존하는 애플리케이션 또는 웹 리소스를 나타냅니다. 이는 사용자의 신원을 확인한 후 접근을 허용해야 하는 기업 비용 관리 애플리케이션으로 생각하면 됩니다.

SAML 인증 흐름

SAML 인증 흐름에는 사용자, IdP 및 SP 간의 일련의 안전한 교환이 포함됩니다:

1. 사용자 접근 초기화: 사용자가 SP에서 보호된 리소스에 접근하려고 시도합니다(예: 비용 관리 애플리케이션에 접근 시도).
2. IdP로 리디렉션: 사용자를 인증할 수 없는 SP는 인증을 위해 사용자를 IdP로 리디렉션합니다.
3. IdP에서의 인증: 사용자는 IdP의 로그인 페이지와 상호작용하며, 검증을 위한 자격 증명을 제공합니다.
4. SAML 단언 생성: 성공적인 인증 후 IdP는 SAML 단언을 생성합니다. 이 XML 문서에는 사용자의 검증된 신원 속성에 대한 정보가 포함됩니다.
5. 단언 전달: IdP는 SAML 단언을 SP에 안전하게 전송합니다.
6. 단언 검증: SP는 디지털 서명을 사용하여 단언의 진위 및 무결성을 면밀히 검토합니다. 이를 통해 단언이 조작되지 않았고 신뢰할 수 있는 IdP에서 출처가 확인됩니다.
7. 접근 허용(또는 거부): 단언이 유효한 경우, SP는 해당 단언에서 관련 사용자 속성을 추출하고 요청한 리소스에 대한 접근을 허용합니다. 유효하지 않은 경우, 접근이 거부됩니다.

SAML의 주요 구성 요소

• SAML 단언: SAML의 핵심으로, 이러한 XML 문서에는 사용자 신원 정보 및 기타 권한 부여 관련 데이터가 포함됩니다.
• 메타데이터: 이러한 XML 파일은 통신을 위한 청사진 역할을 합니다. IdP와 SP는 메타데이터를 교환하여 서로의 기능 및 구성 세부 사항(예: 지원되는 프로토콜 및 보안 인증서)을 이해합니다.
• 프로토콜: 정의된 프로토콜 집합은 인증 및 권한 부여를 위한 메시지 형식 및 통신 흐름을 규정합니다. 일반적인 예로는 SAML SOAP 바인딩(SOAP 메시징용) 및 SAML HTTP 바인딩(웹 브라우저 통신용)이 있습니다.

SAML 보안 고려 사항

• 디지털 서명: SAML 단언은 IdP에 의해 디지털 서명되어 진위를 보장하고 무단 수정을 방지합니다.
• 안전한 통신: 엔티티(사용자, IdP, SP) 간의 통신은 데이터를 전송 중에 보호하기 위해 HTTPS를 사용하여 암호화되어야 합니다.
• 속성 공개 제어: IdP는 SAML 단언에서 어떤 사용자 속성이 공개될지를 제어합니다. 이는 최소 권한 원칙을 준수하여 공개되는 사용자 데이터의 양을 최소화합니다.

SAML의 장점

• 중앙 집중식 인증: 여러 애플리케이션에서 단일 로그인을 가능하게 하여 사용자 경험을 간소화합니다. 사용자는 다양한 리소스에 접근하기 위해 한 번만 인증하면 됩니다.
• 강화된 보안: 사용자 인증의 책임이 잠재적으로 더 안전하고 중앙집중화된 IdP로 이동하여 전체 보안 태세를 향상시킬 수 있습니다.
• 확장성: 단일 IdP 인프라 내에서 증가하는 SP 수를 지원하여 더 큰 사용자 기반을 위한 안전한 접근 관리를 촉진합니다.
• 표준화: 다양한 공급업체의 IdP 및 SP 솔루션 간의 상호 운용 가능한 SSO를 위한 명확하게 정의된 프레임워크를 제공합니다. 이는 유연성을 촉진하고 통합을 간소화합니다.

OAuth 2.0과 SAML 간의 차이점 요약

Apidog - 좋아하는 인증 프레임워크 구현하기

API 도구는 올바른 API 개발에 필수적입니다. 개발자가 전체 API 수명주기를 제어할 수 있는 완벽한 API 도구는 Apidog입니다.

Apidog로 OAuth 2.0 구현하기

새로 생성된 요청에 OAuth 2.0 인증을 적용하는 방법을 살펴보겠습니다.

새 요청을 생성한 후, 위의 이미지에서 볼 수 있는 것처럼 OAuth 2.0 인증 유형을 선택하세요.

Apidog를 사용한 API 엔드포인트 테스트

API 개발 단계에서 수정이 이루어진 후, API가 여전히 의도한 대로 작동하는지 확인해야 합니다. Apidog를 사용하면 각 API의 엔드포인트를 테스트할 수 있습니다.

올바른 API 엔드포인트를 타겟으로 하려면, 먼저 테스트하고자 하는 해당 API 엔드포인트를 삽입해야 합니다. 의도한 API URL을 포함한 후, 엔드포인트에 사용할 파라미터를 포함시키세요(관련이 있는 경우).

아직도 API 엔드포인트 테스트 방법에 대한 확신이 부족하다면, 이 기사를 읽어보세요!

결론

OAuth 2.0과 SAML은 모두 중요한 역할을 합니다. OAuth 2.0은 API에 대한 접근을 세밀하게 제어할 수 있는 능력으로 빛을 발합니다. 사용자 자격 증명을 저장할 필요를 없애고 어떤 자원에 접근할 수 있는지에 대해 세부적인 제어를 제공함으로써, OAuth 2.0은 API 보안 취약점에 대한 공격 표면을 현저하게 줄입니다.

SAML은 웹 애플리케이션을 위한 SSO를 통해 사용자 경험을 간소화하는 데 뛰어나지만, API 접근 제어를 직접적으로 다루지 않습니다. 따라서 APIs를 보호하고 세밀한 접근 제어를 보장하기 위해 OAuth 2.0이 단연 최고입니다. API 보안과 표준화된 접근 방식에 초점을 맞춘 OAuth 2.0은 현대 애플리케이션 생태계 내의 소중한 자원을 보호하기 위한 이상적인 선택입니다.