07.SSO(Single Sign On)

게시 2024/02/13 업데이트 2024/02/16

By Kim Jung Wook 13 분읽는 시간

SSO(Single Sign On)

한 번의 로그인을 통해 여러 어플리케이션(서비스)를 이용할 수 있게 하는 서비스를 말한다
장점
- 여러 웹사이트의 암호를 기억할 필요없이, 사용자는 하나의 로그인 창구를 통해 여러 웹사이트에 접근할 수 있는 권한을 손쉽게 얻을 수 있다.
- 한번의 로그인으로 여러 웹사이트 동시 접근이 가능하고, 업무의 생산성이 향상
- 여러 웹사이트의 암호를 각각의 서비스에서 관리하지 않아도 되기 때문에, 이러한 인증과정에 필요한 보안 시스템의 비용이 절감된다.
- 연결된 모든 웹사이트에 동일하게 높은 수준의 보안 시스템을 적용할 수 있다
- 사용자가 이전보다 훨씬 편리하게 여러 웹사이트를 이용할 수 있다.
Delegation Model과 Propagation Model 2가지 모델이 있다.

1. Delegation Model

Target Service에서 현재 사용중인 인증방식을 새롭게 변경하기 어려운 경우에 사용한다
사용자의 인증 정보를 Sing On Agent에서 관리하여 대신 로그인 해주는 방식이다
- 1.Target Service1에 로그인 하기위한 정보가 id/pw인 경우,
- 2.Sign On Agent가 Authentication Infos에 Target Service1의 로그인 정보가 있는지 확인하고,
- 3.있다면 user를 대신하여 Sign On Agent가 Target Service1으로 로그인을 대신 해준다.

2. Propagation Model

통합 인증을 수행하는 Authentication Service에서 Authentication Token(인증 토큰)을 발급 받는다.
- 1.user가 Target Service1로 접근하기 위해 발급받은 인증 토큰을 Target Service1으로 전달한다.
- 2.Target Service1에서는 인증 토큰을 보고 인증받은 user인지 파악한다.

SSO 구현방식

일반적으로 SSO는 SAML, OAuth2.0, OIDC 방식으로 구현한다. 각 방법마다 간략한 차이점이 있다.

.	SAML	OAuth2.0	OIDC
Format	XML	JSON	JSON
Authorization	O	O	X
Authentication	O	Pseudo-authentication	O
Best Suited for	SSO for Enterprise(Not well suited for mobile)	API authorization	SSO for consumer apps

Authorization : 인가, 내가 보유하고 있는 권한에 대한 표시(관리자, 사용자)
Authentication : 인증, 내가 누구인지에 대한 표시(회원, 비회원)

1. SAML

인증정보를 제공하는 곳(Sign On Agent / Authentication Service)과 서비스를 제공하는 곳(Target Service)사이에서 인증 정보를 교환하기 위해 사용되는 프로토콜 또는 규칙의 집합
XML 기반의 표준 데이터 포멧을 갖는다.
SAML이 등장한 이후로 대부분의 기업이 독자적인 인터페이스 또는 특정 SSO 솔루션을 통해 시스템을 구축하지 않고, 인증 정보를 XML이라는 공통 포멧으로 생성하고 이를 암호화하여 제 3자에게 내용을 노출시키지 않고 데이터를 수신해야 하는 위치까지 안전하게 전달할 수 있게 되었다.

이 때 생성되는 XML을 Assertion이라고 부르는데, Assertion 내부에는 ID 공급자 이름, 발행일, 만료일 등의 정보가 포함되어 있다.

인증 과정

유저가 인증 서비스에 접근하면, Service Provider가 해당 유저의 과거 인증 여부를 확인한다.
Service Provider가 인증 요청(SAML Request)를 생성하고, 이를 클라이언트(Browser)에 전송한다.
User의 Browser가 전달받은 SAMLRequest를 Identity Provider로 리다이렉트한다. 중요한 것은 Service Provider와 Identity Provider는 직접 통신하지 않는다
Identity Provider는 SAMLRequest를 파싱하고, User를 인증한다
인증이 성공하면 SAMLResponse를 생성하여 User의 Browser로 전송한다. SAMLResponse는 XML 형식이다. 내부에 SAMLAssertion을 포함하고 있다.
Identity Provider는 Browser에 Session Cookie를 설정하고, 이를 Browser에 캐싱한다.
SAMLResponse가 Service Provider의 Assertion Consumer Service의 URL 주소로 POST된다.
Assertion Consumer Service는 SAMLResponse를 검증한다
검증 결과가 유효하면 User가 요청한 서비스로 이동한다

문제점
SAMLRequest, SAMLResponse 모두 XML 형식이기 때문에 모바일 또는 Native Application이 아닌 Browser에서만 동작한다

2. OAuth2.0

Authorization(인가)을 위한 개방형 표준 프로토콜
자원의 소유자를 대신하여 3rd party application에게 자원의 접근 권항을 위임하는 방식이다.
모바일 플랫폼에서 사용하기 어려운 SAML 방식의 단점을 보안하기 위해 만들어졌으며, JSON 기반으로 동작한다
사용자의 동의 및 인증만 완료되면, 3rd party application에 계정 정보와 같은 중요한 정보를 공유하지 않아도 자원에 접근할 수 있게된다.
이처럼 OAuth는 사용자의 정보를 외부와 공유하지 않고도 자격이 증명되었다는 인증만으로 Application에서 자원을 사용할 수 있도록 할 수 있다.

2.1 토큰

OAuth 방식의 가장 큰 특징은 토큰이 사용된다는 것인데, 토큰의 종류는 2가지가 있다
1.. Access Token
자원의 소유자로부터 자원을 사용할 수 있다는 허가(권한)을 받았다는 것을 증명하는 토큰이다.
일련의 문자열로 되어있다.
토큰을 발급한 서비스에서만 해당 토큰의 정보를 알고 있다.

SAML의 SAMLAssertion과 동일하게 보이지만, 자원의 사용 권한에 대하여 허가를 받는다는 특징만 같을 뿐 Access Token은 인증 대상에 대한 정보를 포함하고 있지 않다.
즉, Authorization은 가능하지만 Authentication은 불가능 하다

토큰을 요청하면, redirect_url 값을 함께 요청해서 토큰이 발급받을 위치를 미리 지정한다.
요청단계에서 지정하는 이유는 악의적인 사용자가 토큰 발급 위치를 마음대로 변경할 수 있다면, 해당 사용자는 마음대로 자원에 접근을 할 수 있게된다.
이를 막기 위해 Access Token 발급 요청 시점에 Service Provider 내부에 redirect_url을 등록한다.
2.. Refresh Token
결국 Access Token이 탈튀되면 악의적인 사용자가 마음대로 자원에 접근할 수 있게 되는데, 이를 막기 위해 일정 시간이 지나면 Access Token을 사용하지 못하도록 하는 유효기간을 설정해둔다
유효기간이 지나면 사용자는 다시 자원의 소유자에게 Access Token을 새로 발급 받아야 하는데, 이러한 번거로움을 피하기 위해 Refresh Token이 있다.
Refresh Token은 Access Token과 같이 발급받게 되는데, 일반적으로 Access Token보다 유효기간이 길게 책정된다는 특징이 있다.
Refresh Token의 유효기간도 만료되면, 사용자는 초기 토큰을 발급받았던 것 처럼 새로운 토큰을 발급 받아야 한다

하지만 Refresh Token은 보안적으로 매우 취약한 공격대상이 될 수 있다.
악의적인 사용자는 Refresh Token만 알아도 새로운 Access Token을 만들어 기존의 Access Token을 무효화 할 수 있다.
심지어 Refresh Token은 Access Token보다 긴 유효기간을 갖기 때문에 OAuth방식의 취약점을 더욱 드러낸다고 볼 수 있다.
이를 보안하기 위한 것이 OIDC 방식이다.

2.2 인증 과정(Authorization Code Grant)

인증과정은 4개의 엔티티가 존재한다.
- Resource Owner : 자원 소유자, 사용자(User)
- Client : 3rd party application
- Service Provider : 서비스 제공자
  - Resource Server : 자원 서버
  - Authorization Server : 권한 인증 서버

Service Provider에 Access Token을 받을 Client의 주소(redirect_url)를 입력한다
Resource Owner(User)가 Client에게 서비스를 요청한다
Client의 Session에 Access 정보가 있는지 확인 후, 있다면 해당 정보를 반환한다.
없다면 Client에서 Service Provider의 Authorization Server로 Authorization Code를 요청한다
- 요청 파라미터 : client_id, redirect_url, scope, response_type
- scope : 요청하고자 하는 권한의 범위
- 이미 Authorization Server내에 정보(code)가 존재하면 이를 반환한다.
Authorization Server에 정보가 없기 때문에, 로그인 팝업을 사용자에게 띄운다.
로그인 시 허용하게 될 권한에 대한 메시지 창을 띄운다
로그인 정보와 redirect_url값이 유효하다면, Authorization code를 redirect_url로 전달(응답)한다
- Authorization code : Client가 Resource Owner에게 자원 사용을 허락받았다는 표시이다.
Client가 Authorization Server로 Access Token을 요청한다
- 요청 파라미터 : client_id, client_secret, redirect_url, authorization_code
결과 값 반환
Client는 Access Token을 이용하여 Resource Server로 부터 자원(사용자 정보)에 접근한다
- 자원을 요청할 때 Header에 Access Token을 세팅한다
- Authorization: Bearer
Resource Server는 Access Token이 유효한지 확인 후 , scope가 아직 만료되지 않은 경우 정보를 반환한다.