[Security] SSO 개념 (SAML, OAuth, OIDC)

 
IT 회사에서는 특정 서버에 대한 접근 제어 / DB 접근 제어 / AWS 콘솔 및 권한 부여 등을 관리하기 위해 다양한 솔루션들을 도입하고, 혹은 단일 관리 포인트로 두어 관리하곤 합니다.
 
예를 들어 AWS 멀티 어카운트 환경에서 IAM Role에 대해 관리하기 위한 consoleMe, 서버 혹은 DB 접근 제어를 위한 ChakraMax, DBSafer, TelePort, QueryPie, Systems Manager의 Session Manager 등이 있겠습니다.
 
이러한 내용들을 이해하는데 필요한 기본 개념이 있는데 바로 SSO, SAML, OAuth, JWT, OIDC, .. 등이 있습니다.
 
위와 같은 보안에 대한 기반 지식을 이해하고 있어야 보안 솔루션을 도입하는 데 있어 좀 더 효율적으로 관리할 수 있기에 정리하였습니다.
 
 
Ref: https://gruuuuu.github.io/security/ssofriends/
 
위의 블로그 및 여러 레퍼런스 문서들을 보며 공부한 내역을 정리하였습니다.
 

---

1. 개요

Client가 특정 서비스를 사용하기 위해서는 인증(Authentication)과 인가(Authorization)의 절차가 필요하다.

여기서 인증(Authentication)은 유저가 누구인지 확인하는 절차이며,
인가(Authorization)은 유저가 요청(Request)하는 자원(Resource)에 대해 권한(Permission)이 있는지 확인하는 절차이다.

로그인 ⇒ 인증(Authentication)
로그인한 뒤, 특정 사용자가 xx할 권한 ⇒ 인가(Authorization)

근데 여기서, 만들어야 하는 서비스가 1~2개일 경우는 상관이 없겠지만 수십개가 넘어가게 될 경우 각 서비스마다 권한 서비스를 만들어주고, 관리해야 하는 번거로움이 발생할 수 있게 된다.
이러한 이유로 인해 최근엔 대형 회사들(Google, Naver, Facebook)을 통해 로그인할 수 있도록, 이를 단일 포인트(SSO)로 관리하여 다양한 서비스를 사용할 수 있도록 하고 있다.

⇒ 여기서 나오는 개념들이 SSO, SAML, OAuth, OIDC 등이 있을 수 있다.
 
그럼 SSO는 무엇이며, SSO를 구현할 수 있는 메커니즘들은 무엇이 있는지, 각각 어떤 방식으로 인증 혹은 인가를 수행하는지 확인해보도록 한다.
 

2. SSO(Single Sign On)

개념 자체는 정말 간단하다.
 
단일 로그인으로 여러 애플리케이션을 이용할 수 있도록 해주는 서비스이다.

 
 
### 작동 원리

SSO는 일반적으로 2가지 모델로 구분된다.

1. Delegation Model
대상 서비스의 인증 방식을 변경하지 않고, 사용자의 인증 정보를 Agent가 관리하여 대신 로그인해주는 방식
(Target Service에 로그인하기 위한 정보를 agent가 해당 정보를 가지고 있고 로그인할 때 유저 대신 대상 서비스로 정보를 전달하여 로그인시켜 주는 원리)

 
 
2. Propagation Model
통합 인증을 수행하는 곳에서 인증을 받아 ‘인증 토큰'이란 것을 발급받는다.
유저는 서비스에 접근할 때 발급받은 인증 토큰을 이용하여 서비스에 접근하게 되는 것이다.

 
 

2-1) SAML (Security Assertion Markup Language)

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

SAML은 인증 정보를 XML 포맷으로 생성하고, 이 XML 데이터를 암호화하여 제 3자에게 노출시키지 않고 Endpoint에 전달할 수 있다.
이 때 생성한 XML은 Assertion이라고 부른다.

 

인증 방식

SAML의 인증이 어떻게 이루어질까? (3가지 역할에 대해 이해)
User : 인증을 원하는 사용자
Identity Provider : 인증 정보 제공자
Service Provider : 서비스 제공자

### 단점
SAMLRequest & Response는 XML 형식이기 때문에 Browser을 통해서만 동작 가능
⇒ 모바일이나 Native Application에서는 부적절
 

2-2) OAuth 2.0 (Open Authorization)

Authorization(인가)를 위한 개방형 표준 프로토콜이다.

사용자 동의를 받고 Third-Party App과 중요 정보(계정, ..)을 공유하지 않고도 자원에 접근할 수 있게 된다.

즉 OAuth는 사용자가 자격 증명을 공유하지 않고도 App에 리소스를 액세스 할 수 있도록 해준다.
(XML이 아닌 JSON 기반으로 동작한다.)
 

Access Token

OAuth의 핵심은 Access Token인데, Access Token은 임의의 문자열 값이고, 토큰을 발급해 준 서비스만이 해당 토큰의 정보를 알고 있다.
⇒ Resource Owner가 자신의 정보(Resource)를 넘겨주는 것에 대해 동의한다는 의미이다.
토큰을 요청할 때 redirect_uri 값을 같이 요청하여 발급받을 위치를 지정하게 된다.
⇒ OAuth를 사용하는 Service Provider들은 Access Token을 발급받을 위치인 Redirect_uri를 등록해야 한다.

 

Refresh Token

Access Token은 탈취당하면 안되는 중요 Token인데, 만약 탈취를 당하게 되면 다른 사용자가 나의 정보에 접근할 수 있게 된다.
고로 OAuth에서는 일정 시간이 지나면 AccessToken을 사용하지 못하도록 Refresh Token을 두어 유효기간을 설정하게 된다.
 
Refresh Token은 Access Token보다 유효기간이 길며, Access Token이 만료되도 Refresh Token이 만료되지 않는 이상 로그인 없이 계속 발급받을 수 있다.
 
 
 
### 인증 방식 #1 - Authorization Code Grant
가장 많이 사용하고 있는 Authorization Code Grant(권한 코드 인증) 방식.

Roles
    Resource Owner : 자원 소유자, User
    Client : 클라이언트 (Third party App)
    Service Provider : 서비스 제공자
        Resource Server : 자원 서버
        Authorization Server : 권한 서버

 
### 인증 방식 #2 - Access Token이 만료되었을 경우
Access Token이 만료될 경우 Client는 더 이상 Resource Server로부터 Resource를 가져올 수 없기 때문에, Access Token을 재 요청해야 한다.

 
### 인증 방식 #3 - Refresh Token이 만료되었을 경우
다시 로그인해야 함
 

2-3) OIDC (Open ID Connect)

OIDC는 권한 허가 프로토콜인 OAuth 2.0을 이용하여 만든 인증(Authentication) 레이어이다.

OAuth는 Authorization을 위한 기술이며, Access Token은 특정 리소스에 대한 권한을 부여받기 위한 메커니즘을 제공한다.
고로 OIDC를 통해 Authentication(인증)을 위한 ID Token이라는 토큰을 통해 OIDC 인증을 수행하게 된다.
 
 
### ID Token

Access Token은 Bearer 토큰 형식이지만,
ID Token은 JWT (Json Web Token) 형식이다.

JWT는 Header, Payload, Signature 3가지 부분이 담겨 있는 Token이다. ID Token을 얻으면 Client는 Payload 부분에 Encoded 된 사용자 정보를 얻을 수 있다.

Payload에는 Claims라는 필드를 포함하게 되는데 기본적은 Claims는 다음과 같다.

{
  "iss": "<https://server.example.com>",
  "sub": "24400320",
  "aud": "s6BhdRkqt3",
  "exp": 1311281970,
  "iat": 1311280970
}

 
### 인증 Flow
로그인 시, id_token 토큰을 별도로 발급받게 되고 해당 Token을 통해 User의 인증을 구현한다.

 

3. OAuth2, SAML, OIDC 간단 비교

SAML
Format : XML
Authorization : O
Authentication : O
Best Practice : SSO For Enterprise (Mobile X)
 
OAuth 2.0
Format : JSON
Authorization : O
Authentication : Pseudo-authentication ( ~= X )
Best Practice : API Authorization
 
OIDC
Format : JSON
Authorization : X
Authentication : O
Best Practice : SSO For Consumer Applications