SSO (Single Sign On)

SSO

한번의 로그인으로 여러개의 애플리케이션들을 이용 할 수 있게 해주는 서비스.

✅ SSO가 도입된다면 서비스마다 개별로 계정을 만드는 대신 하나의 계정으로 연관된 서비스들을 사용 할 수 있게 된다.

👉 사용자는 여러개의 계정(비밀번호)을 일일히 기억할 필요가 없게 되고, 관리자로써는 서비스별로 인증시스템을 구축 할 필요가 없게 되어 하나의 계정으로 여러개의 리소스에 대한 사용자 접근을 관리 할 수 있게 됨.

종류

• SAML (Security Assertion Markup Language)
• OAuth
• OIDC

✅ SAML

인증정보 제공자와 서비스 제공자 간의 인증 및 인가 데이터를 교환하기 위한 XML기반의 표준 데이터 포멧

👉 SAML은 인증정보를 XML 포맷으로 생성하고, 이 XML 데이터를 암호화 함으로써 제 3자에게 내용을 노출시키지 않고 최종 수신자에게 전달 할 수 있다.
이 때 생성한 XML을 XML Assertion이라고 함.

XML Assertion 예시)
Assertion에는 ID 공급자 이름, 발행일 및 만료일 같은 정보가 포함

인증 플로우

1. 서비스 요청

👉 유저가 서비스에 접근, SP는 해당에 유저가 이미 인증을 했는지 체크

2. SSO 서비스 이동

👉 인증되지 않은 유저 일 경우 인증 요청을 생성하여 클라이언트에 전송 (SAML Request를 생성하여 유저에게 전송)
SP는 IDP와 직접 연결되지 않고 유저의 브라우저에서 SAML Request를 Redirect 함

3. SSO 서비스 요청

👉 IDP 는 SAML Request를 파싱하고 유저 인증 진행
(인증 방식: 패스워드, PKI....)

4. SAML 응답

👉 인증이 성공하게 되면 SAML Response를 생성하여 유저의 브라우저에 전송 (SAML Assertion이 포함되어 있음)

👉 IDP는 웹브라우저에 Session Cookie를 설정하고 해당 정보는 브라우저에 캐싱 됨.

5. (POST) SAML 응답 전송

👉 유저는 SP의 ACS(Assertion Consumer Service)의 URL에 SAML Response를 POST함

6. 서비스 응답

👉 ACS는 SAML Response를 검증하고 유효하다면 유저가 요청한 서비스로 유저를 Forwarding 함
✅로그인 성공

⛔ 단점

• SAML Request, SAML Response는 XML 형식이라 브라우저를 통해서만 동작 가능
  (모바일이나 Native Application에는 부적절)

✅ OAuth 2.0 (Open Authorization 2.0)

"Authorization"을 위한 개방형 표준 프로토콜
Third-Party APP에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임

OAuth는 사용자가 자격 증명을 공유하지 않고도 app에서 리소스에 액세스 할 수 있다.

OAuth는 모바일 플랫폼에서의 SAML의 단점을 보완하기 위해 개발되었으며, SAML과 다르게 XML이 아닌 JSON을 기반으로 함

사용자 인증이 아닌 권한 인증

예시 ) 서드파티 앱을 사용하여 페이스북에 접근권한(Access Token) 부여