SAML과 OAuth를 사용한 페더레이션 로그인
답변:
그들은 다른 문제를 해결합니다.
SAML 은 사용자가 누구인지, 그의 속성 집합이 무엇인지에 대한 정보를 공유하고 무언가에 대한 액세스 권한을 부여 / 거부하거나 인증을 요청하는 방법을 제공하도록 정의 된 표준 집합입니다.
OAuth 는 무언가에 대한 액세스 권한을 위임하는 것에 관한 것입니다. 당신은 기본적으로 누군가가 당신처럼 행동하도록 허용하고 있습니다. 가장 일반적으로 사용자를 대신하여 작업을 수행 할 수있는 액세스 API를 부여하는 데 사용됩니다.
그들은 완전히 다른 두 가지입니다.
도움이 될만한 몇 가지 예.
OAuth는 트위터를 생각합니다. Google 버즈 와 트위터를 사용 중이고 두 가지를 동기화 할 수있는 앱을 작성하고 싶다고 가정 해 보겠습니다. 기본적으로 앱과 트위터간에 신뢰를 구축 할 수 있습니다. 처음으로 앱을 Twitter에 연결하려면 기본 메시지를 통해 Twitter에 로그인하면 확인 상자가 나타나고 ""앱 이름 "에 대한 액세스 권한을 부여 하시겠습니까?"라는 메시지가 표시됩니다. "예"를 클릭하면 신뢰가 구축되고 이제 앱이 Twitter에서 귀하의 역할을 할 수 있습니다. 게시물을 읽고 새 게시물을 만들 수 있습니다.
SAML-SAML의 경우 관련되지 않은 두 멤버십 시스템 간의 "계약"유형을 생각해보십시오. 우리의 경우 US Airways와 Hertz를 사용할 수 있습니다. 한 사이트에서 다른 사이트로 이동할 수있는 공유 자격 증명 세트는 없지만 Hertz가 US Airways에 "거래"를 제공하려고한다고 가정 해 보겠습니다. (나는 이것이 극단적 인 예라는 것을 알고 있지만 저를 참아주십시오). 비행기를 구입하면 회장 회원에게 무료 렌터카를 제공합니다. US Airways와 Hertz는 어떤 형태의 신뢰를 설정하고 사용자를 식별하는 방법을 설정합니다. 우리의 경우 "연합 ID"는 이메일 주소이며 Hertz는 US Airways ID 제공자가 정확하고 안전한 방식으로 토큰을 제공 할 것이라고 신뢰하는 한 가지 신뢰 집합이 될 것입니다. 항공편을 예약 한 후 US Airways ID 공급자는 토큰을 생성하고 사용자를 인증 한 방법을 채울뿐만 아니라 우리의 경우 그 사람에 대한 "속성"을 채 웁니다. 가장 중요한 속성은 US Airways의 상태 수준입니다. 토큰이 채워지면 어떤 유형의 참조를 통해 전달하거나 URL로 인코딩되고 Hertz에 도착하면 토큰을보고 유효성을 검사하고 이제 무료 렌트카를 허용 할 수 있습니다.
이 SAML 예제의 문제점은 많은 경우 중 단 하나의 특수한 사용 사례라는 것입니다. SAML은 표준이며이를 구현할 수있는 방법은 거의 없습니다.
또는 권한 부여에 관심이 없다면 SAML 및 OpenID 를 통해 인증을 주장한다고 거의 주장 할 수 있습니다.
한 번 봐 가지고 이 간단한 설명이 여기에 요약을 :
많은 사람들이 SAML, OpenID 및 OAuth의 차이점에 대해 혼란 스럽지만 실제로는 매우 간단합니다. 겹치는 부분이 있지만 여기에 세 가지를 구별하는 매우 간단한 방법이 있습니다.
OpenID – 소비자를위한 싱글 사인온
SAML – 엔터프라이즈 사용자를위한 싱글 사인온
OAuth – 애플리케이션 간 API 인증
OO 디자인 패턴에 익숙한 사람들에게는 래퍼 패턴에 대한 좋은 결과가 있다고 생각 합니다 . 에 대해 생각하다Facade , Decorator 및 Proxy 패턴을 . 근본적으로 이것들은 모두 똑같습니다. 그들은 단지 래퍼 일뿐입니다 . 차이점은 각 패턴 의 의도 입니다 .
마찬가지로 SAML, OAuth 및 OpenID는 모두 일부 비공개 상호 작용을 위해 서비스 제공 업체 / ID 기관으로 리디렉션 한 다음 원래 타사 앱으로 리디렉션 하는 공통 기본 메커니즘을 통해 서로 다른 의도 를 촉진 합니다.
네트워크를 둘러 보면 프로토콜의 기능이 겹치는 것을 알 수 있습니다. OAuth를 통한 인증 은 완벽하게 합리적입니다. OAuth를 통한 SSO는 SAML 및 OpenID가 특히 페더레이션 ID에 맞춰져 있기 때문에별로 의미가 없을 수 있습니다.
질문 자체 에는 기업 컨텍스트에서 SAML이 SSO 용 OAuth보다 더 적절하게 들립니다 . 기업 아이덴티티와 통합하려는 타사 앱을 보면 이미 SAML / LDAP / Radius 등과 통합하도록 설계되었음을 알 수 있습니다. IMO OAuth는 인터넷 상호 작용에 더 적합합니다. 대기업 환경에서 서비스 지향 아키텍처를 구성하는 애플리케이션 또는 애플리케이션 간.
권한 부여 규칙은 다른 방법으로도 회사 환경에서 지정할 수 있습니다. LDAP는이를위한 일반적인 도구입니다. 사용자를 그룹으로 구성하고 애플리케이션 권한을 그룹 멤버십에 연결하는 것은 널리 퍼져있는 접근 방식입니다. LDAP도 인증에 사용할 수 있습니다. Active Directory는 좋은 예이지만 OpenLDAP를 선호합니다.
SAML (Security Assertion Markup Language)은 SSO (Single Sign On), 연합 및 ID 관리를 달성하기위한 일련의 표준입니다.
예 : 사용자 (주장)가 SAML을 통해 구성된 SSO가있는 항공편 예약 웹 사이트 인 AirFlyer (ID 제공자)와 셔틀 예약 웹 사이트 Shutler (서비스 제공자)로 인증합니다. Flyer에 인증되면 사용자는 인증없이 Shuttler에서 셔틀을 예약 할 수 있습니다.
OAuth (Open Authorization)는 리소스 인증을위한 표준입니다. 인증은 다루지 않습니다.
예 : 사용자가 Instagram 계정 (OAuth 공급자)에서 사진을 가져올 수 있도록 허용하는 사진 공유 모바일 앱 (OAuth 소비자)은 몇 시간 후에 만료되는 사진 공유 앱에 임시 액세스 토큰 또는 키를 보냅니다.
SAML에는 다른 사용자가 귀하의 사이트에 "로그인"할 수 있도록 선택할 수있는 다양한 "프로필"이 있습니다. SAML-P 또는 SAML Passive는 매우 일반적이며 설정이 매우 간단합니다. WS-Trust는 유사하며 웹 사이트 간의 연합도 허용합니다.
OAuth는 인증을 위해 설계되었습니다. 여기에서 자세한 내용을 읽을 수 있습니다.
SAML인증 용으로 주로 단일 사인온 시나리오 에서 사용됩니다 . OAuth자원 표현의 권한 부여입니다.
JSON 웹 토큰 (JWT) 은 SAML XML 토큰의 대안입니다. JWT는 OAuth와 함께 사용할 수 있습니다.
연합이라는 용어는 실제로 시스템 간의 연결 ID를 의미합니다. SSO와 관련이 있지만 동일하지는 않습니다. 이 블로그 게시물은 연합이 실제로 의미하는 바에 대해 정말 유용하다는 것을 알았습니다.