SSO 관련 인증 프로토콜 (SAML, OAuth2.0, OIDC)

 

사내에서 서비스 중 admin 쪽에 Okta 관련 연동을 도입한다고 하기에 미리 공부하기 위해 끄적여본다.. 

Okta 연동관련하여 크게 3가지로 구현할 수 있는데 SAML, OAuth과 OIDC이다. 3가지 프로토콜에 대해서 알아보자

 

우리는  여러 사이트를 돌아다니면서 서비스를 사용하기 위해 계정을 만들고 로그인을 하게 됩니다.

예전에는 여러 사이트마다 각자 계정을 만드는 일이 잦았는데 최근엔 대형 회사들 (Google, Naver, Kakao 등)의 계정 SSO 로그인 기능을 활용해 대신 할 수 있게 되었습니다.

 

 

 

SSO (Single-Sign-On) 란?

이름 그대로 단일 로그인, 즉 한번의 로그인으로 여러개의 어플리케이션들을 이용할 수 있게해주는 서비스 입니다.

 

 

SSO가 없다면 사용하고자 하는 서비스마다 따로따로 계정을 갖고 있어야 하지만,

 

 

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

사용자로써는 여러개의 계정(비밀번호)을 일일히 기억할 필요가 없게 되고,

관리자로써는 서비스별로 인증시스템을 구축할 필요가 없게되며 하나의 계정으로 여러 시스템과 플랫폼, 기타 리소스에 대한 사용자 접근을 관리할 수 있게 됩니다.

 

 

 

SSO 작동원리

SSO를 구현하기 위한 표준은 여러가지이지만 기본 패턴은 동일합니다. 일반적으로 두가지 모델로 구분됩니다.

 

1. Delegation Model

권한을 얻으려는 서비스의 인증방식을 변경하기 어려울 때 많이 사용되는 방식입니다.
대상 서비스의 인증방식을 변경하지 않고, 사용자의 인증 정보를 Agent가 관리하여 대신 로그인 해주는 방식입니다.
만약 Target Service에 로그인하기 위한 정보가 admin/passwd라면 Agent가 해당 정보를 가지고 있고 로그인할때 유저대신 대상 서비스로 정보를 전달해 로그인시켜줍니다.

 

 

2. Propagation Model

통합 인증을 수행하는 곳에서 인증을 받아 '인증 토큰'이라는 것을 발급받게됩니다.
유저가 서비스에 접근할 때 발급받은 인증토큰을 서비스에 같이 전달하게 되고, 서비스는 토큰정보를 통해 사용자를 인식할 수 있게 하는 방식입니다.

서비스의 특성에 따라서 두가지 모델을 혼용해서 전체 시스템의 SSO를 구성하는 것이 일반적입니다.

 

 

 

SSO 구현방법

SSO 시스템은 대표적으로 SAML/OAuth/OIDC 3가지 방식이 존재합니다.

 

1. SAML (Security Assertion Markup Language)

SAML은 인증 정보 제공자와, 서비스 제공자 간의 인증 및 인가 데이터를 교환하기 위한 XML기반의 표준 데이터 포맷입니다.

SAML이 출현하기 이전, 기업들은 독자적인 인터페이스 또는 특정한 SSO솔루션을 사용하여 SSO를 구축해야 했습니다.
SSO솔루션들은 Private망에서 인증정보를 Cookie에 담아 사용하는 등의 방법을 사용하였지만, Public 망에서는 보안적으로 문제가 있었습니다.

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

 

 

  https://appx.com/sample/metadata.php
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/>
  <samlp:RequestedAuthnContext Comparison="exact">
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

- SAML 요청 예제

 

SAMLRequest, SAMLResponse는 XML형식이라 브라우저를 통해서만 동작 가능
=> 주로 웹 기반 Application에 사용되므로 모바일이나 Native Application에는 부적절한 형식

 

 

 

2. OAuth 2.0

OAuth 2.0 (Open Authorization 2.0)는 'Authorization'을 위한 개방형 표준 프로토콜입니다.
Third-Party App에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공합니다.
즉, 사용자의 동의를 받고 Third-Party App과 중요한 정보(계정)를 공유하지 않고도 자원에 접근할 수 있게 해줍니다.

OAuth는 사용자가 자격 증명을 공유하지 않고도 app에서 리소스에 액세스 할 수 있습니다.
즉, 3rd앱이 다른서비스에 있는 정보를 서비스에서 안전하게 사용할 수 있다는 의미입니다.

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

또한 SAML은 Authentication/Authorization(인증/인가)를 둘 다 다루는데 반해 OAuth는 Authorization를 목적으로 설계되었습니다.

 

Authentication : 인증. 내가 누군지
Authorization: 인가. 내가 가지고 있는 권한

 

Access Token

OAuth의 핵심은 Access Token입니다.

Access Token은 임의의 문자열 값이고, 토큰을 발급해 준 서비스만이 해당 토큰의 정보를 알고 있습니다.

이 토큰은 Resource Owner가 자신의 정보(Resource)를 넘겨주는 것에 대해서 동의한다는 증표입니다.

SAML에서 SAMLAssertion이 안에 User의 인증정보를 갖고 있어서, 해당 Assertion을 가지면 User의 인증/권한을 사용할 수 있듯이
OAuth에서는 Access Token이 이와 비슷한 역할을 수행하게 됩니다.
(Access Token는 인증에 대한 정보는 없고, 권한에 대한 허가만 가능)

또한, 서비스제공자는 Token이 탈취될 위험성이 존재하기 때문에 발급받을 위치인 Redirect URL을 등록해야합니다.

 

Refresh Token

Access Token은 탈취당하면 악의적인 사용자가 나의 정보에 접근할 수도 있어 OAuth에서 가장 중요한 토큰입니다.

때문에 OAuth에서는 일정 시간이 지나면 AccessToken을 사용하지 못하도록 유효기간을 설정해둡니다.

보통 짧게는 몇분에서 길어야 반나절 정도로 유효기간을 설정해두는데요, 이 방식은 짧으면 짧을 수록 안전하지만 만료될때마다 다시 Token을 받아야 한다는 단점이 있습니다. (다시 로그인해야한다는 의미)

그래서 Access Token을 간편하게 발급받을 수 있는 Refresh Token을 Access Token과 함께 받게 됩니다.
Refresh Token은 Access Token보다 유효기간이 길어서 Access Token이 만료되더라도 Refresh Token이 만료되지 않는 이상 로그인 없이 계속 발급받을 수 있습니다.

 

 

 

 

3. OIDC (OpenID Connect)

OIDC는 권한 허가 프로토콜인 OAuth 2.0를 이용하여 만들어진 인증 레이어 입니다. 이전 프로토콜인 SAML보다 구현하기 쉽고 더 유연한 구문을 제공합니다.

OAuth는 위에서 언급했듯이, Authorization을 위한 기술이지 Authentication을 위한 기술은 아닙니다.
OAuth에서 발급하는 Access Token은 일시적으로 특정 권한을 허가해준 토큰일 뿐이지 사용자에 대한 정보는 담고 있지 않습니다.
Access Token을 발급하기 위해 사용자 인증을 하긴 하였으나 Access Token이 사용자 인증을 위해 사용되어선 안됩니다.

그래서 OIDC에서는 인증을 위해 ID Token이라는 토큰을 추가하였습니다.

 

ID Token

Access Token이 Bearer 토큰 형식이었다면,
ID Token은 JWT(JSON Web Token)형식입니다.

JWT는 header, payload, signature 3가지 부분이 담겨있는 토큰입니다. ID Token을 얻으면 Client는 payload부분에 인코드 된 사용자 정보를 얻을 수 있습니다.

※ Access Token은 ID Token과 다르다는 것에 유의
ID Token - 사용자 정보가 포함되어 있으며 애플리케이션이 인증된 사람을 확인
Access Token - 요청된 리소스에 액세스할 수 있는 권한을 애플리케이션에 부여하는데 사용

 

 

기본적인 토큰발급과 refresh token으로 토큰을 갱신하는등 일련의 동작들은 OAuth와 동일합니다.
다른 점은 로그인 시, id_token이라는 별도로 발급받게되고 해당 토큰을 통해 유저의 인증을 손쉽게 할 수 있게 됩니다.

 

 

SAML vs OAuth2.0 vs OIDC

마지막으로 3가지 방식의 차이점

	SAML	OAuth2.0	OIDC
포맷형식	XML	JSON	JSON
인증 (Authorization)	O	Pseudo-authentication	O
인가 (Authentication)	O	O	X
적합한 환경	SSO for Enterprise (Mobile X)	API authorization	SSO

 

• SAML : 인증/인가 모두 제공, XML 기반, Enterprise용 SSO구축에 주로 사용
• OAuth2.0 : Authorization만 제공, JSON 기반, 자격증명을 app과 공유하지 않고도 자원을 사용할 수 있게 해줌
• OIDC : OAuth2.0과 함께 주로 사용, JSON 기반, Mobile과 Native app에서 사용될 수 있는 구조를 가짐

 

 

OAuth로도 인증(Authentication)을 할 수 있어 위와 같이 인증하는 것을 Pseudo Authentication이라 불리지만, 여러 보안위협들이 존재하기 때문에 OIDC나 SAML과 같은 방식을 따는 것이 안전하다

 

 

 

OIDC와 SAML 차이점
복잡성 - SAML은 다양한 구성옵션을 제공하며 유연성을 제공하지만, 서로 다른 구현 간에 호환성 문제가 발생할수 있고 어렵다.
구현 - OIDC는 SAML보다 개발자 친화적이며 XML보다 처리하기 쉬운 JWT를 사용하므로 구현하기가 더 쉽다. 많은 라이브러리가 구축되어 있고 SAML은 구현 및 관리가 어려울 수 있다.

 

 

---

Ref

https://it-ist.tistory.com/251

https://fusionauth.io/blog/saml-and-oidc-difference