SSO(Single Sign On)
한번의 로그인으로 여러 허용된 자원에 접근할 수 있도록 하는 기술입니다.
구현 방식
1. Delegation Model
권한을 얻으려는 서비스의 인증방식을 변경하기 어려울 때 많이 사용되는 방식입니다.
Target Service에 로그인하기 위한 정보가 id/password 라면, Agent 가 해당 정보를 가지고 있고 Agent에 로그인할 때, 유저대신 대상 서비스로 정보를 전달해 로그인시켜줍니다.
2. Propagation Model
SSO에서 인증을 받아 대상 애플리케이션으로 전달할 토큰 생성합니다.
애플리케이션에선 SSO의 토큰을 검증하고 인증된 것으로 처리합니다.
서비스의 특성에 따라서 두 가지 모델을 혼용해서 전체 시스템의 SSO를 구성하는 것이 일반적입니다.
인증/인가
대표적으로 세 가지 방식이 있습니다. SAML/OAuth/OIDC
1. SAML(Security Assertion Markup Language)
SAML은 인증 정보 제공자와, 서비스 제공자 간의 인증 및 인가 데이터를 교환하기 위해 XML기반의 표준 데이터 포맷입니다.
SAML이 출현하기 이전, 기업들은 독자적인 인터페이스 또는 특정한 SSO 솔루션을 사용하여 SSO를 구축해야 했습니다.
SSO 솔루션은 Private 망에서 인증정보를 Cookie 에 담아 사용하는 등의 방법을 사용했지만, Public 망에서는 보안적으로 문제가 있었습니다.
SAML은 인증정보를 xML 포맷으로 생성하고, 이 XML 데이터를 암호화하여 제 3자에게 내용을 노출시키지 않고 최종 수신자에게 전달할 수 있습니다.
이 때 생성한 XML을 Assertion이라고 부릅니다.
Assertion에는 ID 공급자 이름, 발행일 및 만료일 같은 정보가 포함되어 있습니다.
- 인증 플로우
SAML의 인증 플로우 에는 3가지 역할 있습니다.
-
User : 인증을 원한는 사용자
-
Identity Provider(IDP) : 인증 정보 제공자
-
Service Provider(SP) : 서비스 제공자
-
User → SP : 서비스 요청
-
SP → User → IDP : SSO 서비스 요청 (SP 는 IDP와 직접 연결 X, redirect)
-
IDP → User : SAML 응답
-
User → SP : SAML 응답 전송
-
SP : 서비스 응답
❗이미 로그인을 성공한 뒤로는 2 번에서 SP → User로 넘어가면 User의 브라우저에서 SAML을 캐싱하고 있기 때문에, 별도의 로그인 창을 띄우지 않고 SAML을 SP에 전송합니다.
단점
SAMLRequest, SAMLResponse는 XML 형식이라 브라우저를 통해서만 동작가능 합니다.
모바일이나 Native Apllication에서는 부적절한 형식입니다.
2. OAuth 2.0
OAuth 2.0은 Authorization을 위한 개방형 표준 프로토콜 입니다.
OAuth 는 모바일 플램폼에서의 SAML의 단점을 보완하기 위해 개발 되었으며, SMAL과 다르게 XML이 아닌 JSON 기반입니다.
또한 SAML은 Authentication/Authorization 둘 다 다루는데 반해 OAuth는 Authorization을 목적으로 설계되었습니다.
Access Token
OAuth의 핵심은 Access Token 입니다.
Access Token은 임의의 문자열 값이고, 토큰을 발급해준 서비스만이 해당 토큰의 정보를 알고 있습니다.
이 토큰은 Resouce Owner가 자신의 정보(Resource)를 넘겨주는 것에 대해서 동의 한다는 증표입니다.
3. OIDC(OpenId Connect)
OIDC는 권한 허가 프로토콜인 OAuth 2.0을 이용하여 만들어진 인증 레이어 입니다.
OAuth에서 발급하는 Access Token은 일시적으로 특정 권한을 허가해준 토큰일 뿐이지 사용자에 대한 정보를 담고 있지는 않습니다.
Access Token을 발급하기 위해 사용자 인증을 하긴 했으나 Access Token을 사용자 인증을 위해 사용해서는 안됩니다.
그래서 OIDC 에서는 인증을 위해 ID Token 이라는 토큰을 추가했습니다.
기본적인 토큰 발급과 리프레쉬 토큰으로 토큰을 갱신하는 일련의 동작들은 OAuth와 동일합니다.
다른 점은 로그인 시, id_token 이라는 별도의 토큰을 발급받고 유저의 인증을 손쉽게 할 수 있습니다.
(기존 Oauth 성공시 JWT 발급을 진행해 서비스 로그인 유지를 대신 해준다고 생각하면 될 듯 합니다)
- id_token의 autdience 를 통해 유효한 client로 부터 온 토큰인지 검증
- id_token으로부터 user정보를 추출한 뒤 DB와 교차검증
OIDC 프로바이더의 공개 키를 가져와서 서명을 확인하는 작업으로 JWT 유효성 검사를 진행합니다.
SAML vs OAuth2.0 VS OIDC
| SAML | OAuth2.0 | OIDC | |
|---|---|---|---|
| Format | XML | JSON | JSON |
| Authorization | O | O | X |
| authentication | O | Pseudo-authentication | O |
OAuth2.0 Pseudo Authentication
OAuth는 Authorization을 목표로 설계되었으며, OpenId는 Authentication을 목표로 설계된 툴입니다.
OAuth로 인증을 시도하는 사례들을 볼 수 있는데 이를 Pseudo Authentication이라고 부릅니다.
고민
현재 SSO를 구축해야 하는 상황입니다. 6개의 서비스에 통합인증을 적용 해야합니다. 많은 서비스의 로그인 방식을 변경하기 쉽지 않아 Delegation Model을 적용 해보려 합니다.
출처
