OpenID와 SAML의 차이점은 무엇입니까?
답변:
원본 OpenID 2.0 및 SAML
두 가지 인증 프로토콜이며 기술 수준이 다릅니다.
멀리서, 사용자가 인증을 시작할 때 차이가 시작됩니다. OpenID에서 사용자 로그인은 일반적으로 인증을 담당하는 리소스의 HTTP 주소입니다. 반면 SAML은 사이트와 자격 증명 공급자 간의 명시 적 신뢰를 기반으로하므로 알 수없는 사이트의 자격 증명을받는 것이 일반적이지 않습니다.
OpenID 아이덴티티는 인터넷을 쉽게 이용할 수 있습니다. 개발자는 매우 다른 OpenID 제공 업체에서 온 사용자를 받아 들일 수 있습니다. 반면에 SAML 제공자는 일반적으로 미리 코딩해야하며 선택한 ID 제공자만으로 애플리케이션을 연합해야합니다. 허용되는 OpenID 자격 증명 공급자 목록을 좁힐 수는 있지만 이것이 일반적인 OpenID 개념과 반대되는 것 같습니다.
OpenID를 사용하면 임의의 서버에서 온 ID를 수락합니다. 누군가가 주장하고 있습니다 http://someopenid.provider.com/john.smith. 이것을 데이터베이스의 사용자와 어떻게 일치시킬 것인가? 예를 들어이 정보를 새 계정으로 저장하고 사용자가 사이트를 다시 방문 할 때이를 인식하는 등의 방법이 있습니다. 사용자에 대한 다른 정보 (이름 또는 이메일 포함)는 신뢰할 수 없습니다.
반면에 응용 프로그램과 SAML ID 공급자간에 명시적인 신뢰가있는 경우 이름과 전자 메일을 포함하여 사용자에 대한 전체 정보를 얻을 수 있으며이 정보는 신뢰 관계로 인해 신뢰할 수 있습니다. 이는 ID 제공자가 어떻게 든 모든 정보의 유효성을 검증했다고 믿고 응용 프로그램 수준에서 정보를 신뢰할 수 있음을 의미합니다. 사용자가 알 수없는 공급자가 발급 한 SAML 토큰을 사용하는 경우 응용 프로그램은 인증을 거부합니다.
OpenID Connect 및 SAML
(섹션은 07-2017 추가, 08-2018 확장)
이 답변은 2011 년이며 OpenID는 OpenID 2.0을지지했습니다 . 나중에, 어딘가에 2012, OAuth2.0에이 출판되었으며, 2014 년, 오픈 ID 연결 (더 자세한 타임 라인 여기 ).
요즘 읽는 사람이라면 OpenID Connect는 원래 답변과 동일한 OpenID가 아니며 OAuth2.0의 확장 세트입니다.
이 답변 은 개념적 관점에서 약간의 빛을 비출 수 있지만 OAuth2.0 배경을 가진 사람에게 매우 간결한 버전은 OpenID Connect 가 실제로 OAuth2.0이지만 액세스 토큰 후에 사용자 정보 를 쿼리 하는 표준 방법을 추가한다는 것입니다 사용할 수 있습니다.
원래 질문을 참조하면 OpenID Connect (OAuth2.0)와 SAML의 주요 차이점은 응용 프로그램과 아이덴티티 공급자간에 트러스트 관계가 구축되는 방식입니다.
SAML은 디지털 서명에 대한 신뢰 관계를 구축하고 아이덴티티 공급자가 발급 한 SAML 토큰은 서명 된 XML이며 응용 프로그램은 서명 자체와 인증서를 확인합니다. 사용자 정보는 다른 정보 중에서 SAML 토큰에 포함됩니다.
OAuth2는 애플리케이션에서 ID 로의 직접 HTTP 호출에 대한 신뢰 관계를 구축합니다. 요청에는 액세스 프로토콜 (프로토콜 흐름 중에 응용 프로그램에 의해 획득 됨)이 포함되고 응답에는 사용자에 대한 정보가 포함됩니다.
OpenID Connect는이를 확장 하여 응용 프로그램에서 자격 증명 공급자로의 호출과 관련된 추가 단계 없이 자격 증명을 얻을 수 있도록합니다 . 아이디어는 사실을 기반으로 그 사실 문제에 오픈 ID를 연결 제공 이 토큰은
access_token, 바로 그 하나의 OAuth2.0에 문제와 새의id_token인 JWT 토큰, 서명 Identity 공급자에 의해. 애플리케이션은id_tokenJWT 토큰에 포함 된 클레임을 기반으로 로컬 세션을 설정 하기 위해 를 사용할 수 있지만 다른 서비스를 추가로 쿼리id_token하는 데 사용할 수는 없습니다 .access_token. OpenID Connect는 SAML2 (서명 된 토큰)와 OAuth2 (액세스 토큰) 사이의 하이브리드로 생각할 수 있습니다. OpenID Connect는 둘 다 포함하기 때문입니다.
OpenID와 SAML2는 모두 동일한 페더레이션 ID 개념을 기반으로합니다. 다음은 그들 사이의 차이점입니다 ..
- SAML2는 싱글 사인 아웃을 지원하지만 OpenID는 지원하지 않습니다
- SAML2 서비스 공급자는 SAML2 아이덴티티 공급자와 연결되어 있지만 OpenID 신뢰 당사자는 OpenID 공급자와 연결되어 있지 않습니다. OpenID에는 OpenID가 제공되면 해당 OpenID 공급자를 동적으로 검색하는 검색 프로토콜이 있습니다. SAML에는 아이덴티티 공급자 검색 서비스 프로토콜을 기반으로하는 검색 프로토콜이 있습니다.
- SAML2를 사용하면 사용자가 SAML2 IdP에 연결됩니다. SAML2 식별자는 발급 한 SAML2 IdP에만 유효합니다. 그러나 OpenID를 사용하면 식별자를 소유하고 원하는 OpenID 공급자에 매핑 할 수 있습니다.
- SAML2에는 다른 바인딩이 있지만 OpenID에있는 유일한 바인딩은 HTTP입니다.
- SAML2는 서비스 공급자 (SP)가 시작하거나 ID 공급자 (IdP)가 될 수 있습니다. 그러나 OpenID는 항상 SP를 시작했습니다.
- SAML 2는 XML을 기반으로하지만 OpenID는 그렇지 않습니다.
- 지난 3 년 동안 개발 된 대부분의 응용 프로그램은 OpenID Connect 만 지원했습니다.
- 2018 년 5 월 Microsoft Azure AD가 제출 한 8B + 인증 요청의 92 %가 OpenID Connect 지원 응용 프로그램에서 온 것입니다.
SAML과 다른 인증 표준 (Open.inc 포함)의 가장 큰 차이점은
SAML은 , ID 공급자 (IDP)와 서비스 공급자 (SP)가 필요 손 전에 서로 알고 사전 구성 , 정적 인증 및 권한 부여를. OpenId (+ Connect)에는 이러한 요구 사항이 없습니다.
누가 데이터에 액세스하고 있는지를 완전히 제어하려는 IDP에게 중요합니다. 표준의 일부는 특정 SP에 제공되는 것을 구성하는 것입니다.
예를 들어, 은행은 규정 또는 기타 엄격한 보안 규칙으로 인해 일부 사전 정의 된 서비스를 제외한 서비스에 사용자가 액세스하는 것을 원하지 않을 수 있습니다.
그렇다고 OpenId IDP가 그러한 제한을 시행 할 수는 없습니다. OpenID 구현자는 액세스를 제어 할 수 있지만 OpenID의 목적은 아닙니다.
사전 정의 된 엄격하고 정적 인 액세스 제어 차이점을 제외하고 개념적으로 (기술적으로는 아님) OpenID Connect 및 SAML 은 유사합니다.
결론적으로 SP 인 경우 고객이 요구하는 사항을 지원해야합니다.
- 고객이 개별 최종 사용자 고객 인 경우 (예 : Google ID 사용) SAML을 잊어 버리십시오. OpenID Connect를 사용하십시오.
- 고객이 직원이 서비스를 사용하고 서비스에 제공 할 정적 데이터 목록 만 내보내기를 원하는 은행 인 경우 은행에서 SAML을 지원하기를 원할 것입니다. 은행은 고객 제한으로 OpenID를 구현할 수 있습니다.
SAML과 OpenID는 모두 ID 공급자 (약칭 IdP), 즉 분산 인증 프로토콜 (싱글 사인온 ID)의 역할을 할 수 있습니다.
S의 보 안 경우 → ssertion M arkup L의 anguage ( SAML은 ) 보안 도메인에서 인증 및인가 데이터를 교환하기위한 정보의 집합이다. SAML 도메인 모델에서 자격 증명 공급자는 특별한 유형의 인증 기관입니다. 특히 SAML 자격 증명 공급자는 SAML의 SSO 프로필과 함께 인증 어설 션을 발급하는 시스템 엔터티입니다. 이러한 인증 어설 션을 사용하는 신뢰 당사자를 SAML 서비스 공급자라고합니다. 출처
O 펜 ID C는 connect를 ( OIDC가 )의 OAuth 2.0 인증 프레임 워크의 위에 인증 층이다. 표준은 OpenID Foundation에서 제어합니다. OAuth는 인증 프로토콜이 아닌 인증 프로토콜 용이며 인증 프로토콜로 특별히 설계된 OpenID입니다. OIDC는 간단한 JWT (JSON Web Web Tokens)를 사용하며 JavaScript로 사용하기가 더 쉽습니다.
사용자가 Facebook 또는 Twitter로 로그인하려는 경우 OAuth를 사용하십시오. 사용자가 "다른 사람이 자신의 ID를 소유하고 싶지 않기 때문에"자신의 OpenID 공급자를 실행하는 목 수염 인 경우 OpenID를 사용하십시오.
