Token Authentication vs. SAML

Token Authentication vs. SAML

토큰 인증(Token Authentication)

토큰 인증은 사용자의 자격 증명(보통 사용자 이름과 비밀번호)을 검증한 후, 서버가 발급한 토큰을 통해 이후 요청에서 인증을 처리하는 방식이다.

기본 개념 및 작동 원리

1. 인증 흐름:
   • 사용자가 로그인 정보(ID/비밀번호)를 제출한다.
   • 서버는 이를 검증하고 서명된 토큰을 생성한다.
   • 클라이언트는 토큰을 저장하고 이후 요청에 포함시킨다.
   • 서버는 토큰의 서명과 내용을 검증하여 사용자를 인증한다.
2. 토큰 형식:
   • 가장 일반적인 형식은 JWT(JSON Web Token)이다.
   • JWT는 헤더, 페이로드, 서명의 세 부분으로 구성된다.
   • 토큰은 Base64Url로 인코딩되어 HTTP 헤더로 전송된다.

주요 특징

• 무상태(Stateless): 서버는 세션 상태를 저장할 필요가 없다.
• 확장성: 서버 간에 세션 정보를 공유할 필요가 없어 수평적 확장이 용이한다.
• 클라이언트 중심: 토큰은 클라이언트에 저장되고 관리된다.
• 다양한 플랫폼 지원: 웹, 모바일, API 등 다양한 환경에서 사용 가능하다.
• 자체 포함적(Self-contained): 토큰 자체에 사용자 정보와 권한이 포함될 수 있다.

SAML(Security Assertion Markup Language)

SAML은 서로 다른 도메인 간에 인증 및 권한 부여 데이터를 교환하기 위한 XML 기반 표준이다. 주로 엔터프라이즈 환경에서 SSO(Single Sign-On)를 구현하는 데 사용된다.

기본 개념 및 작동 원리

1. 주요 구성요소:
   • 서비스 제공자(SP): 사용자가 접근하려는 애플리케이션이나 서비스
   • 신원 제공자(IdP): 사용자 인증을 담당하는 시스템
   • SAML 어설션(Assertion): 사용자 신원과 속성 정보를 담은 XML 문서
2. 인증 흐름(SP 시작 흐름 기준):
   • 사용자가 서비스 제공자(SP)에 접근을 시도한다.
   • SP는 사용자를 신원 제공자(IdP)로 리디렉션한다.
   • 사용자가 IdP에 로그인한다.
   • IdP는 SAML 어설션을 생성하고 사용자를 SP로 다시 리디렉션한다.
   • SP는 SAML 어설션을 검증하고 사용자에게 접근 권한을 부여한다.

주요 특징

• 엔터프라이즈 중심: 주로 기업 환경에서 사용된다.
• XML 기반: 모든 SAML 메시지와 어설션은 XML 형식이다.
• 신뢰 관계: SP와 IdP 간에 사전 설정된 신뢰 관계가 필요하다.
• 풍부한 속성: 사용자에 대한 다양한 속성 정보를 전달할 수 있다.
• 서버 중심: 대부분의 처리가 서버 측에서 이루어진다.

심층 분석

인증 흐름 비교

토큰 인증 흐름(JWT 예시):

1
2
3
4
5

1. 클라이언트: 사용자 이름/비밀번호 제출
2. 서버: 자격 증명 검증 → JWT 생성 → JWT 반환
3. 클라이언트: JWT 저장(로컬 스토리지, 쿠키 등)
4. 클라이언트: API 요청 + Authorization 헤더에 JWT 포함
5. 서버: JWT 서명 검증 → 요청 처리 → 응답 반환

SAML 인증 흐름(SP 시작):

1
2
3
4
5

1. 사용자: 서비스 제공자(SP) 접근
2. SP: 인증 요청 생성 → 사용자를 IdP로 리디렉션(요청 포함)
3. 사용자: IdP에 로그인(이미 세션이 있으면 자동 처리)
4. IdP: 사용자 인증 → SAML 어설션 생성 → 사용자를 SP로 리디렉션(어설션 포함)
5. SP: SAML 어설션 검증 → 사용자 세션 생성 → 서비스 접근 허용

기술적 구현 차이

토큰 인증 구현(Node.js, JWT 예시):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

// JWT 생성
const jwt = require('jsonwebtoken');
const token = jwt.sign(
  { userId: user.id, username: user.username },
  'your-secret-key',
  { expiresIn: '1h' }
);

// JWT 검증
function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).send('인증 토큰이 필요합니다');
  
  try {
    const decoded = jwt.verify(token, 'your-secret-key');
    req.user = decoded;
    next();
  } catch (err) {
    return res.status(403).send('유효하지 않은 토큰입니다');
  }
}

SAML 구현(Node.js 예시, passport-saml 사용):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

const passport = require('passport');
const SamlStrategy = require('passport-saml').Strategy;

passport.use(new SamlStrategy({
  path: '/login/callback',
  entryPoint: 'https://idp.example.com/SSO',
  issuer: 'your-app-entity-id',
  cert: 'IdP-public-certificate'
}, (profile, done) => {
  return done(null, {
    id: profile.nameID,
    email: profile.email,
    attributes: profile.attributes
  });
}));

// SAML 인증 요청 라우트
app.get('/login',
  passport.authenticate('saml', { failureRedirect: '/login', failureFlash: true }),
  (req, res) => res.redirect('/')
);

// SAML 응답 처리 라우트
app.post('/login/callback',
  passport.authenticate('saml', { failureRedirect: '/login', failureFlash: true }),
  (req, res) => res.redirect('/')
);

장단점 분석

토큰 인증의 장단점

장점:

• 구현이 상대적으로 간단하다.
• 무상태 특성으로 서버 확장성이 우수하다.
• 다양한 클라이언트 플랫폼(웹, 모바일 등)에 적합하다.
• 네트워크 오버헤드가 적다(작은 토큰 크기).
• REST API와 잘 통합된다.
• 개발 및 디버깅이 쉽다.

단점:

• 토큰이 클라이언트에 저장되므로 도난 위험이 있다.
• 토큰 폐기가 어렵다(발행된 토큰은 만료될 때까지 유효).
• 토큰 크기 제한으로 많은 정보를 포함하기 어려울 수 있다.
• 보안 구현의 책임이 개발자에게 더 많이 있다.
• 표준화된 SSO 프레임워크가 없다.

SAML의 장단점

장점:

• 완전한 SSO 솔루션을 제공한다.
• 엔터프라이즈 환경에서 널리 채택되어 성숙한 생태계가 있다.
• 풍부한 사용자 속성 정보를 전달할 수 있다.
• 강력한 보안 기능(디지털 서명, 암호화 등)을 제공한다.
• 세션 관리 및 실시간 세션 취소가 가능하다.
• 잘 확립된 표준으로 다양한 벤더 제품과 호환된다.

단점:

• 구현 복잡성이 높다.
• XML 처리로 인한 성능 오버헤드가 있다.
• 모바일 애플리케이션 지원이 제한적이다.
• 설정 및 디버깅이 어렵다.
• 현대적인 SPA(Single Page Application) 통합이 까다롭다.
• 메시지 크기가 크다(XML 구조).

사용 시나리오

토큰 인증이 적합한 경우

1. 모바일 애플리케이션: 경량화된 토큰이 모바일 환경에 적합하다.
2. API 중심 아키텍처: RESTful 서비스와 마이크로서비스에 이상적이다.
3. 단일 페이지 애플리케이션(SPA): 프론트엔드 중심 애플리케이션에 적합하다.
4. 리소스 제한 환경: 처리 오버헤드가 적어 리소스 효율성이 중요한 경우에 유용하다.
5. 스타트업과 중소기업: 빠른 구현과 간단한 설정이 필요한 경우에 적합하다.

SAML이 적합한 경우

1. 엔터프라이즈 SSO: 여러 기업 애플리케이션 간의 통합 인증에 이상적이다.
2. 규제 산업: 금융, 의료, 정부 기관 등 높은 보안 요구사항을 가진 산업에 적합하다.
3. 기존 시스템 통합: 레거시 시스템과의 통합이 필요한 경우에 유용하다.
4. B2B 통합: 기업 간 서비스 연결에 적합하다.
5. 복잡한 사용자 속성 관리: 다양한 사용자 속성과 권한 정보를 전달해야 하는 경우에 강점이 있다.

현대적인 접근 방식 및 하이브리드 솔루션

현대적인 시스템에서는 종종 두 기술의 장점을 결합한 하이브리드 접근 방식을 채택한다:

1. SAML + JWT: SAML을 통한 초기 인증 후 API 호출을 위한 JWT 발급
2. IdP 다양화: 다양한 인증 프로토콜(SAML, OpenID Connect 등)을 지원하는 ID 제공자 사용
3. API 게이트웨이: API 게이트웨이를 통한 토큰 변환 및 프로토콜 브리징

토큰 인증 vs. SAML 비교

용어 정리

참고 및 출처