회사에서 제공하는 서비스들이 점점 다양해지면서,
유저가 1회의 로그인으로 다른 서비스들도 이용할 수 있도록 SSO(통합 인증 방식)를 도입하게 되었다.
이에 따라 우리 팀에서 운영하던 서비스의 어드민도 기존 로그인 페이지와 로직을 걷어내고
로그인 인증 방식은 SSO 서버를 통해서 진행하는 방식으로 변경했다.
우선 SSO가 어떤건지 알아보자.
SSO (Single Sign-On)
SSO(Single Sign-On)은 모든 사용자 애플리케이션 로그인을 하나의 로그인으로 줄이는 중요한 클라우드 보안 기술이다.
이것을 더 쉽게 설명해 놓은 글이 CLOUDFLARE 공홈에 있어서 가져와봤다.
만약 바에 입장한 고객이 추가로 술을 구매하려고 할 때마다 신분증을 제시해야 한다고 상상해 보세요.
일부 고객은 계속되는 확인에 불만을 표시할 수도 있습니다.
그렇기 때문에 대부분의 식당에서는 고객의 신원을 한번만 확인한 다음 저녁 시간 내내 고객에게 술을 제공합니다.
이는 SSO 시스템과 다소 비슷합니다.
이처럼 SSO 인증 방식을 사용하면 유저는 ID를 한 번만 확인받고, 여러 서비스에 접근할 수 있게 된다.
우리가 어느 순간 자연스럽게 사용하고 있는 OAuth도 SSO의 유형 중 하나이다.
이렇게 SSO를 이용하면 어떤 점이 좋을까?
SSO를 이용함으로써 얻을 수 있는 대표적인 장점 3가지로는 보안성, 생산성 그리고 사용자 경험 향상을 꼽을 수 있을 것이다.
1. 보안성 향상
- 시스템 이용량이 증가하는 서비스에서 SSO를 사용하면 유저는 하나의 인증 정보로 여러 서비스에 로그인 할 수 있기 때문에 비밀번호 재사용 또는 비밀번호 분실로 인한 보안 위험을 줄일 수 있다.
2. 사용자 경험 향상
- 유저는 서비스마다 별도의 로그인 페이지로 이동해서 로그인하지 않아도 되기 때문에 사용자 경험 및 고객 만족도를 크게 향상시킬 수 있다.
3. 서비스 관리 용이
- 관리자는 직원들이 이용하는 서비스마다 인증 시스템을 구축할 필요 없이, 하나의 인증 정보만으로 여러 서비스에 접근하는 유저들을 통제할 수 있다.
이렇듯 SSO의 장점이 많다.
하지만 개인적으로는 SSO를 제대로 구현하지 않으면 오히려 보안적으로도 더 문제가 될 수 있을 것 같다는 생각이 들었다. 그래서 SSO를 도입하기 전에 고려해야 하는 부분에 대해 알아보았다.
SSO 사용 시 고려해야 할 점
1. SSO 서버의 보안 강화
- 만약 SSO 서버의 보안 문제로 비밀번호가 유출됐다면, SSO를 사용하지 않았을 경우보다 피해가 증가하게 된다.
- 또한 아아디 및 패스워드를 분실한 경우 모든 서비스를 이용할 수 없게 되는 문제가 생긴다.
- 따라서, 다양한 방식의 암호화를 통하여 보완해야 한다. (일회성 비밀번호, 생체인식, OTP 방식 인증 등)
2. 도입 비용
- 사내 서버에 SW 를 설치하여 사용하는 경우에는 별도의 개발 및 관리 비용이 필요하다.
- 외부 SaaS 서비스를 이용할 경우, 초기 비용은 저렴하지만 월정액 과금 형태가 많기 때문에 장기간 사용 시 유지 관리 비용이 꾸준하게 발생하게 된다.
- 그렇기에 자체적으로 개발을 할지, 외부 SaaS 를 사용할지 등은 규모와 보안성, 비용 등을 고려하여 판단을 해야한다.
SSO에 대해 GPT에게 더 물어보다 SAML, ODIC 등에 대해 알게됐지만 이렇게 글로만 봐서는 와닿지가 않았다...
그래도 이런 사전 지식을 기반으로 프론트에서 어떻게 통합 인증 방식을 연동했는지에 대한 이야기를 해보려고 햅니다
프론트엔드 SSO 적용기
사실 이런 방식의 통신은 처음 해보기 때문에
로그인 구현 전에 인증 과정을 대략적인 그림으로 그려보았다
결론적으로 인증 서버가 따로 있고, 백엔드 서버가 따로 있다고 생각하고 구현했다
대략 통신 과정은 아래와 같다
- SSO App에서 로그인한다.
- 이때 로그인을 성공한다면 accessToken 이 Cookie 에 박혀있게 된다.
- 그 상태로 어드민 페이지로 redirect 한다.
- redirect 됐으니까 Cookie 이용해서 다시 accessToken과 refreshToken 을 요청한다.
- refreshToken 을 발급 받는다.
- 발급 받은 accessToken 을 이용해서 어드민 서버로 필요한 API를 요청한다.
- 이때 만약 API 응답으로 401일 경우 4번부터 다시 반복하면 된다.
- 만약 SSO 서버로 요청하는 refreshToken API의 응답이 401일 경우 SSO App으로 redirect 한다.
사실 로컬 환경에서는 어떻게 구현해도 상관없지만 개발 편의성을 위해서 로컬에서만 다음 로직을 추가했다.
- 어드민 App.tsx 에서 SSO 서버로 로그인(signIn) API를 요청한다.
- signIn API 응답으로 받은 이 accessToken을 sessionStorage 에 저장하고 어드민 서버와 통신할 때 사용한다.
- 이 accessToken 이 만료되어 토큰을 다시 받아오기까지의 시간안에 API에서 401 나는 경우를 대비해 setInterval을 돌려 토큰을 지속적으로 받아오도록 처리한다.
에러처리
통합 인증을 구현하면서 내가 가장 신경썼던 부분은 API 통신의 에러처리 부분이었다.
일반 백엔드 서버 API와 인증 서버 API의 에러를 처리하는 방식이 다르기 때문에 두 개의 인스턴스를 분리해서 처리했다.
- Admin Backend API 호출 후 인증 에러(401) 발생 시 처리 과정
- token 을 재발급 받아서 기존 요청하려던 API 를 재요청한다
- 만약 401이 한번 발생했다면 return 하여 여러 개의 인증 에러(401)가 한번에 일어나지 않도록 처리한다
- SSO Server 에서 refreshToken 이 만료되어 401 발생 시 처리 과정
- SSO App 로그인 페이지로 바로 redirect 한다
- 로그아웃 처리한다
참고
