웹 기반 통합 인증 (SSO) 구현

통합 인증 (SSO) 구현

최근 여러 자사 서비스들을 개발하면서 전체 서비스들에 대한 통합 로그인 솔루션이 필요하게 되었습니다.

통합 인증(SSO) 서비스 개발을 진행하면서 얻은 지식들을 정리하고 공유해보려고 합니다.

 

SSO란?

먼저 SSO(Single Sign-On)은 1회 사용자 인증으로 다수의 서비스에 로그인을 허용하는 통합 로그인(인증) 솔루션입니다.

SSO는 여러 서비스들이 독립적으로 동작하지만 같은 회사에서 제공하는 서비스일 때 유용합니다.

 

기존 방식

SSO를 사용하지 않고 기존 방식대로 세개의 서비스에 로그인 로직을 따로 구현할 때의 문제점은 다음과 같습니다.

• 사용자: <아이디-비밀번호> 세 쌍을 기억해야 합니다.
• 서비스 개발자: 로그인 화면 세 개, 데이터 베이스 세 개, 로그인 프로세스 세 개를 각각 구현 해야 합니다. 서비스끼리 데이터 싱크를 맞춰야 한다면 구현 난이도는 훨씬 어려워집니다.

 

 

SSO 방식

위와 같은 문제점을 해결하는 방법이 SSO 인증 방식입니다. 각 서비스들에서 인증 로직만 분리하여 하나의 서비스로 제공하는 구조라고 이해하시면 됩니다.

 

 

SP: Service Provider의 약자입니다. '서비스', '어플리케이션'을 SSO 용어로는 SP라고 부릅니다.

IdP: Identity Provider의 약자로, 각 SP들의 인증 로직을 분리하여 구현해 놓은 하나의 웹 서비스입니다.

 

참고 url: https://haneepark.github.io/2018/08/04/sso/

SSO란 무엇인가! 이해해봅시다

 

 

SSO 모델

SSO 구현 모델에는 크게 5가지 방식이 있습니다.

 

1. 인증 대행 모델(Delegation Model)

• 권한을 얻으려는 서비스의 인증 방식을 변경하기 어려울 경우 사용
• 대상 서비스의 인증방식 자체를 변경하지 않고, SSO Agent 가 사용자 인증 정보를 관리하며 대신 로그인해주는 방식
• 만약 Target Service에 로그인하기 위한 정보가 admin/passwd라면, Agent가 해당 정보를 가지고 있고 로그인할 때 유저대신 Target Service에 사용자 정보를 전달해 로그인

 

2. 인증 정보 전달 모델(Propagation Model)

• 웹 기반의 시스템에 주로 사용
• 통합 인증을 수행하는 곳에서 인증을 받아 ‘인증 토큰’을 발급
• 유저가 서비스에 접근할 때 발급받은 토큰을 서비스에 같이 전달하게 되고, 서비스는 토큰정보를 통해 사용자를 인식

 

 

3. Delegation & Propagation

• 웹 환경이라고 하더라도, Propagation 방식이 모두 적용될 수는 없으며, 특히 웹 어플리케이션의 변경이 전혀 불가능하고 사용자 통합이 어려운 경우에는 Delegation 방식을 사용해야 함
• 대상 어플리케이션들이 많이 있고, 어플리케이션의 특성들이 다양한 경우, 각 어플리케이션에 Delegation 방식과 Propagation 방식을 혼용해서 전체 시스템의 SSO를 구성하는 방식

 

4. (Web 기반) One Cookie Domain SSO

• SSO 대상 서비스와 응용 어플리케이션들이 하나의 Cookie Domain 안에 존재할 때 사용됨. 일반적인 기업 내부의 컴퓨팅 환경에서 사용
• 통합 인증을 받은 사용자는 토큰을 발급 받으며, 이 토큰은 Cookie Domain에 Cookie로 설정되어 Cookie Domain 내의 다른 서비스로 접근할 때 자동으로 토큰을 서비스에 제공
  => 서비스에서 동작되는 SSO 에이전트는 토큰으로부터 사용자 신원을 확인하고 요청된 자원에 대한 접근을 허가

 

5. (Web 기반) Multi Cookie Domain SSO

• SSO 대상 서비스와 응용 어플리케이션들이 여러 도메인으로 분산되어 있는 경우 사용
• Multi Domain 환경의 경우, 사용자 인증 및 토큰 발행을 위한 마스터 에이전트가 존재
• 마스터 에이전트는 각 서비스 에이전트의 사용자 인증을 위임 받아 수행하며, 인증된 사용자에게는 토큰을 발급하고 각 서비스 에이전트에게 안전하게 전달
• 서비스 에이전트가 해당 토큰을 자신의 Domain에서 Cookie로 저장하여 사용할 수 있도록 함
• 각 서비스 에이전트의 신뢰도 및 SSO 시스템의 보안 레벨에 따라 다음과 같이 두 가지 방식으로 서비스될 수 있음
  ① One Token for All Multi Cookie Domain
  ② Token for Each Cookie Domain & One Token for Master Agent

 

저희 자사 서비스는 웹서비스 기반이고, 인증 방식 또한 수정이 가능한 환경이었습니다.

여기에 더해 각 서비스들의 도메인이 같았기 때문에 'One Cookie Domain SSO'을 사용하기로 했습니다.

도메인 예시) biz.dever.team, account.dever.team

 

참고 url: https://wiki.wikisecurity.net/wiki:sso

SSO -

 

 

SSO 구현

여러 블로그에서 SSO 구현 방식(표준)이 SAML, OAuth, OIDC가 있다고 하는데, One Cookie Domain SSO 방식에서는 고려하지 않아도 상관없는거 같습니다.

 

자사 SSO 서비스는 토큰 기반 인증을 제공합니다.

그 중에서도 리프레시 토큰은 세션(DB)에 저장하고, 엑세스 토큰은 JWT를 사용하여, 둘 모두 쿠키에 저장하는 방식을 채택했습니다.

 

https://bellmir.tistory.com/45

세션 기반 로그인 vs 토큰 기반 로그인

 

https://velog.io/@y1andyu/%EC%BF%A0%ED%82%A4-%EC%86%8D%EC%84%B1%EB%93%A4

쿠키 속성들

 

 

SSO 시퀀스는 토큰 기반 인증 방식이기 때문에 아래와 같습니다.

토큰 발급 방식의 SSO 구현 다이어그램

 

 

자사 SSO 및 소셜 로그인 구조도

 

---

 

참고 url:

• https://charming-kyu.tistory.com/43
• https://co-no.tistory.com/entry/%EC%84%9C%EB%B2%84-%EA%B3%B5%ED%86%B5-SSOSingle-Sign-On-%EC%9D%B4%EB%9E%80