SSO - Single Sign-On?

개발공부/개발공부

by Dal_pang 2023. 2. 17. 13:07

Single Sign On.

통합 로그인이라고 불리며, Federated Identity를 기반으로 만들어진 기능.

Federated Identity

Federated Authentication .

Federation Identity Management는 Identity Provider와 Service Provider간 사용자 인증에 대해 어떤 정보를 토대로 할것인지 상호 이해를 바탕으로 하는 협약이다.

여기에는 SAML(Security Assertion Markup Language), OAuth, OpenID등이 있다.

OAuth를 예로들자면 개발자는

1. Google API로부터 OAuth credentials를 받아와야한다. 이때 해당 정보는 구글과 해당 회사 두곳이 모두 알고 있는 정보 (예를들어 Client ID, client secret 등)

Client ID : 어플리케이션의 외부 식별자(public identifier). 가능하면 피싱 공격으로 부터 조금더 안전하게 사용하기 위해, 예상 하기 어렵도록 작성하는 것이 권장. 32-character hex string으로 작성하기도 함.

예)

Github: 6779ef20e75817b79602
Google: 292085223830.apps.googleusercontent.com

Client Secret : 어플리케이션과 authorization 서버만 알고있는 secret. 어플리케이션에(Client ID) 대한 비밀번호. 외부 유출되면 안되는 정보! private key같은 개념.

SSO의 주요 인증 프로토콜에는 SAML과 OpenID Connect가 있다.

SAML : Security Assertion Markup Language.

XML 기반으로 작성되어 서비스 간에 유저 Identity를 교환하는 기준.

Zoom, Office 365, Dropbox, Slack 등에서 사용.

OpenID Connect : JWT나 JSON Web Token 을 이용해 서비스간 identity 정보를 교환하는 방식.

Header, Payload, Signature 으로 구성됨.

구글 아이디를 이용해 Gmail, Youtube등에 로그인 할때 사용하는 방식.

==SAML==

[ 기본 SSO 로그인 절차 ]

1) 사용자가 Gmail에 회사 계정으로 로그인을 시도할 경우.

Gmail은 해당 사용자가 회사 도메인으로 로그인을 시도하는 것을 확인하여,

SAML Authentication(인증)을 브라우저에게 반환해준다. (SAR : SAML Authentication Request)

브라우저는 해당 회사의 Identity Provider(SAML 파일에 명시된 업체)에게 redirect해준다.

[ 주요 Identity Provider : Okta, Auth0(AuthZero), OneLogin ]

Identity Provider는 사용자에게 로그인 페이지를 보여주게된다.

사용자가 로그인 정보를 작성하고 submit 하면, Identity Provider는 해당정보로 인증확인 후 사용자에게 SAML 파일을 브라우저에게 응답해준다. 이를 SAML assertion이라고 한다.

[ SAML Assertion : 암호화 인증된 XML 문서로, User Info와 해당 사용자가 접근가능한 곳에 대한 정보를 담고 있다. ]

이후 브라우저는, gmail과 같은 서비스 제공자에게 signed SAML assertion을 전달하고,

서비스 제공자는 이 SAML assertion이 identity provider로 부터 서명을 받은(signed)것인지 확인하는 절차를 걸친다.

[ 이 확인 절차는 주로 public key 암호화를 통해 이뤄진다. ]

확인이 완료되면 서비스 제공자는 SAML assertion에 명시되어 있는 접근가능한 정보를 토대로 브라우저에게 자원들을 전달해준다.

여기까지가 기본 SSO 로그인 절차이다.

https://www.youtube.com/watch?v=O1cRJWYF-g4

[ 사용자가 SSO로 통합된 다른 어플리케이션으로 이동(navigates)할 경우 ]

예를들어, Gmail을 사용하던 사용자가 Workday로 이동할 경우.

Workday는 사용자의 상업 도메인을 감지하여 SAML Authentication Request(SAR)을 브라우저에게 보낸다.

브라우저는 SAR(SAML Authentication Request)을 Identity Provider에게 전달한다.

이때, 이미 사용자는 로그인이 된 상태이므로, 로그인 Process를 건너 뛰고

대신 SAML Assertion For Workday, 즉 Workday 어플리케이션에 맞는 SAML Assertion을 생성한다.

이 SAML Assertion에는 로그인시와 마찬가지로 사용자 정보와, 이 사용자가 접근 허용된 기능들에 대해 명시되어 진다.

SAML Assertion이 브라우저에 반환되면, 브라우저는 서비스 제공자에게 이 SAML Assertion을 전송한다.

서비스 제공자 (이 예제에서는 Workday)가 SAML Assertion을 확인한 후, 해당 유저에게 맞는 접근을 허용하게 된다.

==OpenID Connect==

OpenID Connect는 XML 문서 대신 JWT를 전달 한다는 점이 가장 큰 차이점이다.

자세히 따지자면 SAML과 다르지만, 전반적인 컨셉은 비슷하다고 볼 수 있다.

[ JWT? ]

Signed JSON Document.

둘중 무엇을 사용해야 할까?

둘 모두 보안상 안전하다고 볼 수 있기때문에, 통합시키려고 하는 어플리케이션에 어떤 프로토콜이 더 적용하기 쉬운지가 가장 중요한 쟁점이라고 할 수 있다.

참고링크

https://youtu.be/O1cRJWYF-g4

728x90

'개발공부 > 개발공부' 카테고리의 다른 글

JavaScript 검색 구현 - 검색 키워드로 값 필터링하기. (0)	2023.04.23
Javascript 암호화, 복호화 메서드 (0)	2023.02.27
javascript.info - 모듈 (0)	2023.01.02
javascript.info - 제너레이터와 비동기 이터레이션 (0)	2023.01.02
javascript.info - 프라미스와 async, await(3) (0)	2023.01.02