[ Architecture, Technology ,Web ] SSO(Single Sign On) 그리고 SAML에 대해
이번 프로젝트 내부에서 어쩌다보니
유저 인증 관련 업무를 담당하게 되었고,
해야하는 업무는 내부에 사용했던 적이 없던
새로운 개발 플랫폼에서 SSO의 프로토콜 중
SAML을 이용해 앱의 인증을 구현해야만 했다.
SSO를 생각해본적 조차 없는 상황에
이를 새로운 개발 플랫폼에 도입해야 했기 때문에
많은 시행착오를 겪었으나 구현에 성공하였으며
덕분에 SSO에 대한 전반적인 지식을 쌓을 수 있었다.
이번에는 그러한 과정에서 나온 지식들과 경험을
공유하고자 한다.
SSO에 대한 정의
먼저 사전적 정의 부터 살펴보자.
다만, 기술적인 용어다보니 자주 사용하는 옥스포드 사전에
정의를 찾을 수 없기 때문에
검색으로 찾을 수 있는 정의를 몇 가지 살펴보고 교차 검증을 해보자.
첫 번째 정의를 살펴보자.
Single sign-on (SSO) is an identification method that enables users to log in to multiple applications and websites with one set of credentials.SSO는 웹사이트에서 한 번의 인증(one set of credentials)으로 복수의 어플리케이션에 로그인 할 수 있는 인증(identification) 방법(method) 이다.
두 번째는 위키피디아의 정의이다.
Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.SSO는 독립적이지만 연관되어있는 몇몇 소프트웨어에 대해 하나의 ID로 로그인을 할 수 있도록 하는 인증 구조(scheme)
세부 설명에 조금 차이가 있어 보이지만
전체적인 틀은 매우 비슷해 보인다.
몇 가지 포인트가 되는 단어를 추출해
이를 연결해보자면
아래와 같은 의미를 산출 할 수 있다.
독립적이지만 연관되어 있는 복수의 어플리케이션에서하나의 ID나 한번의 인증으로 로그인 할 수 있는 인증 방법 혹은 구조
독립적이지만 연관되어 있는
복수의 어플리케이션이라는 설명이
조금 복잡해보일 수 있으나
한 번의 로그인으로 Gmail과 사진, 스프레드 시트 등의
어플리케이션에 접근할 수 있는 Google의 서비스를 연상해본다면
이해가 조금 빠를 지도 모르겠다.
이 정의에 다소 수긍할 수 있다면
본격적으로 이야기를 나누어 볼 수 있을 것이다.
SSO 구현의 예
사실 이미 우리 주변 깊숙한 곳에 이미 침투해 있다.
여러가지가 있겠으나
유튜브라는 솔루션의 성공으로
AI 이전 시대에 고부가가치 산업을 주도했던
Google의 모든 솔루션을 보면
멀리가지 않아도 SSO의 구현에 예를 볼 수 있다.
왜냐하면 한번에 구글 로그인으로 메일 뿐만 아니라
스프레트 시트 등의 어플리케이션에도
반복되는 추가 로그인 없이 접속이 가능하기 때문이다.
이는 유튜브도 마찬가지이다.
유튜브에 로그인 한다면 유튜브 뮤직이라는
별도의 앱에 추가 로그인 없이 어플리케이션을 이용할 수 있다.
이는 Google이라는 전체적인 플랫폼이
SSO로 인증처리를 진행하기 때문이다.
즉, SSO란 한 번의 인증으로
지정된 다양한 애플리케이션에 접속할 수 있는 권한을
얻어내는 기술이라고 할 수 있을 것이다.
SAML(Security Assertion Markup Language)에 대해
SAML(Security Assertion Markup Language)은
SSO 내부에서 가장 중요하다고 볼 수 있는
인증 토큰을 작성 그리고 읽기 위한 프로토콜 중 하나 이다.
이 외에도 oAuth라는 인증 토큰이 존재하지만
일반적으로 사용되는 서비스 쪽은
SAML를 사용한다고 보는 것이 옳을 것이다.
왜냐하면 oAuth에는 승인만 할 뿐 인증은 하지 않기 때문이다.
만약 구현하고 싶은 것이
특정 유저 이외에는
접근을 허용하고 싶지 않는 것에 있다면
해당 페이지에 접속한 대상에 대한 인증이 필요하다.
따라서 필연적으로 oAuth는
보안에 문제가 있을 수 밖에 없으며
많은 고객에게 서비스를 제공하는 입장에서는
SAML를 사용할 수 밖에 없다.
참고로 이제 세계 대부분의 사람이 사용하는 구글 플랫폼의
SSO 유저 인증은 이 SAML로 구현되어 있다.
SAML 처리 프로세스
SAML의 경우
먼저 어디서 유저 인증을 할 것 인가에 따라 다르다.
외부 시스템(Identity Providers, Idp)에서 유저 인증을
아니면 SSO 시스템 자체에서 유저 인증을 하느냐에 따라 다를 수 있다.
예컨데, SSO 시스템 자체에서 하게 되는 경우
구글의 SSO 시스템을 이용하고, 구글의 계정을 이용해
유저 인증을 할 경우가 될 것이다.
하지만, 보통 보안 상의 문제로 자사 시스템에서
유저 인증을 해야 하는 경우가 많기 때문에
Idp에서 유저 인증을 하는 경우만 이야기 하려고 한다.
SSO 시스템에서 유저 인증을 하는 경우는
구글 도큐먼트[1] 에 잘 설명되어 있으니 참고하기 바란다.
서비스를 만드는 입장에서는 다소 이 경우가 많은데
왜냐하면, 대게 보안상의 문제로
자신들이 운영하고 있는 서버의 DB안에 존재하는
유저 정보를 통해 유저 인증을 하고 싶기 때문이다.
예컨데, 구글 플랫폼의 전 솔루션(앱)의 접근 권한은
당연하게도 자신들의 서버 안에 있는 유저 정보를 통해
부여하고 이를 컨트롤 하고 싶을 것이고,
네이버도 자신들의 전 솔루션(앱)의 접근 권한은
자신들의 서버 안에 있는 유저 정보를 통해
부여하고 이를 컨트롤 하고 싶을 것이다.
단일 애플리케이션이였다면
조금 다를 수 있으나 SSO의 경우는 신중할 필요가 있다.
내가 참가 했던 프로젝트도 이 경우이다.
반대로 보안이 그렇게 중요하지 않는 서비스라면
대부분의 사람은 구글 계정을 가지고 있을 테니
구글의 서비스를 사용하는 것도 나쁘지 않은 선택이다.
빠른 이해를 위해 위의 과정을 전부 설명하기 보단
몇 가지로 묶어서 설명하도록 하겠다.
나는 이렇게 3개로 간단하게 묶고 싶다.
첫 번째로 유저 인증 페이지로의 리다이렉트 및 Request 토큰 생성
두 번째, SAML Response 토큰 생성
세 번째, SAML Response 토큰 검증 후, 인증 완료
물론 전제 조건으로는 SSO 인증이 되어있지 않을 때이다.
꽤나 복잡해 보일 수 있는 과정이지만,
이 전체 과정은 인증 서비스를 제공해주는 SP(Service Provider)와
인증 서비스를 제공받는 IdP(Identity Providers)간의 상호 신뢰를 위한 과정이다.
따라서 SP에서 1이라는 토큰을 생성하고,
만약 response를 통해 온 결과 값이 동일하게 1이라는 토큰이라면
SP에서 인증을 승인해 주는 그러한 아키텍쳐이다.
물론 그 안에 데이터를 안전하게 전송하기 위한
장치는 있겠지만 말이다.
SAML 처리 프로세스：①유저 인증 페이지 리다이렉트 및 SAML Request 토큰 생성
들어가기 앞서 노파심에 이야기하자면
앞서 설명한바와 같이
나는 이 과정에 어떤 기술이 들어가고
로직적으로 어떤 동작을 하는지에 대해
이야기를 하고 싶은 마음은 없다.
왜냐하면 이미 인터넷에는
이에 대한 훌륭한 글들이 많으며
내가 이를 다시 설명한다 하더라도
큰 의미는 없기 때문이다.
따라서 이번 글의 목적은 SSO가 그리고
SSO 인증 토큰인 SAML 어떤 것이며
이에 대한 청사진과 이를 구현하게 된다면
어떤 결과를 기대할 수 있는지에 대해 이야기하려고 한다.
이 글은 개인적으로는 꽤나 성공적인
그리고 외적으로는 어느정도 유효성은 있을 것이기에
적어도 나의 목표는 달성했다고 할 수 있다.
이제 본격적으로 이야기를 시작해보자.
이 첫 번째 과정은 길게 설명할 필요가 없는데
왜냐하면 정말 간단하기 때문이다.
SSO 인증을 도입한 시스템에
SSO 인증이 이루어지지 않은 유저가 접근하려 한다면
SP는 인증 페이지에 강제로 리다이렉트 시킨다.
예컨데, 당신이 구글 Gmail이라는
이메일 앱에 접속하려고 하며
이를 로그인 한적 없는 디바이스에서 접근하려 한다고 가정해보자.
당연하게도 당신은
구글 SSO 시스템에 의해 인증되어있지 않기 때문에
어떠한 화면으로 강제로 리다이렉트 된다.
그 페이지가 바로 아래와 같은 페이지 이다.
구글 인증 시스템은 이를 감지하고
위에 화면에 해당하는 URL가 담겨있고
이 URL으로 리다이렉트하라는 Request를 유저에게 전송할 것이다.
그리고 브라우저는 서버의 요청에 따라
해당 URL으로 리다이렉트 할 것이며
그에 따른 결과가 위와 같은 화면이다.
SAML 처리 프로세스：②SAML Response 토큰 생성
다음으로 두 번째 블록에 대한 이야기로 넘어가자.
따로 긴 설명이 필요 없을 부분으로 보인다.
SAML 프로토콜에 맞게 Response를 생성에
인증을 하려하는 유저(디바이스 혹은 브라우저)에게 보내는 과정이다.
이 과정에서 IdP가 디지털 서명을 하게 된다.
이 부분에 대해서는
이 과정보다 이 과정에 들어가기
전제 조건 쪽에 시간을 할당하려고 한다.
두 번째 블록에 들어가기 위해서는
유저 쪽에서 인증 번호를 입력하거나
그에 합당하는 어떠한 것을 서버에 주어야만 한다.
흔히 이야기하는 패스워드가 이에 해당한다.
이는 꽤나 예전부터 솔루션으로 쓰여왔던 것이지만
최근에는 추가적인 솔루션이 자주 도입되는데
이는 OTP(One Time Password)라는 것이다.
따라서 SSO를 도입하려 한다면
패스워드에 추가로 OTP를 도입할 것 인지에 대한 생각도 해봐야한다.
물론 이 경우 작업 시간이 추가로 필요하겠지만 말이다.
먼저 구글은 두 가지 솔루션을 사용하였다.
첫 번째, 일반적인 아이디와 비밀번호를 입력하는 보안 솔루션
두 번째, 스마트폰 앱을 이용한 OTP 보안 솔루션
이 두 가지로 이루어져 있다.
여기서
구글의 OTP 솔루션은 조금 독특한 면을 볼 수 있는데
Gmail에 OTP 기능을 넣어
자신들의 솔루션을 이용하도록 유도했다는 점이다.
일반적으로 OTP 앱은 아래 MS에서 제공하는
Microsoft Authenticator 앱과 같이
Microsoft Authenticator 앱과 같이
이 두 가지를 보안 시스템을 에러 없이 통과한다면
②번 Response 토큰 생성 과정에 들어가며
②번 Response 토큰 생성 과정에 들어가며
IdP에게 인증을 받기 위해
IdP의 URL으로 리다이렉트 해
디지털 서명을 완료 후,
응답을 기다리고 있는 브라우저에게
Response 객체를 전달한다.
SAML 처리 프로세스：③SAML Response 검증
다음으로 마지막 세 번째 블록이다.
브라우저로 부터 IdP 경유로 받아온 Response 객체를 검증 한다.
검증 포인트는 신뢰할 수 있는 IdP에서 인증이 이루어진 후
변경되어 있지 않은지를 확인 한다.
검증이 완료되면 해당 유저로 로그인 한다.
구글이라면 우리에게 매우 익숙한
아래와 같은 심플한 화면이 나타날 것 이다.
지금까지 해서 대략적인 SAML 처리 플로우에 대한 이야기를 해봤다.
물론 내가 여기서 설명한 것은
Google의 서비스로 예를 들었기 때문에
Google이 아니라 MS의 Azure나 AWS의 경우 조금 다를 수는 있지만
큰 틀로 보면 크게 다르지는 않을 것 이다.
또한 위에서도 조금 이야기 했듯이
제품을 만드는데에 있어서
이런 솔루션을 굳이 만들 필요 까지는 없을 것이다.
아이디, 비밀번호를 입력하는 솔루션은 매우 일반적이고
OTP 생성 앱은 MS사의 앱을 이용해도 된다.
왜냐하면,
현재로서는 대부분의 서비스는
클라우드 서버에 올라가고 운영되기 때문이며,
SSO는 일반적으로 사용되는 기술이기 때문에
클라우드 서버를 제공하는 서비스에 이미 포함되어 있기 때문이다.
따라서 각 서비스 업체의 SSO를 이용하는 것이 여러모로 좋을 것이다.
SSO 장점과 단점에 대해
다음으로 장점과 단점에 대해 이야기해보자.
결론부터 말하면 단점 보다 장점이 더 크다고 볼 수 있는데
이유는 다음과 같다.
첫 번째로,
한 번의 인증으로 여러가지 애플리케이션에 접속 할 수 있다.
두 번째로,
인증 한 번으로 다 수의 앱에 접속할 수 있기 때문에
서비스를 이용하는 사람에게 있어서
다수의 계정을 만들 필요도 없으며 이를 관리하지 않아도 된다.
이미 많은 서비스에 계정을 등록하고
이를 관리해야만 하는 입장에서 있는 수 많은 이용자에게 있어서
SSO는 매우 편리한 기능이 아닐 수 없다.
사실상 이 두 가지 장점이 다른 단점을
다 상쇄하고도 남는다고 볼 수 있다.
왜냐하면,
여러가지 의미에서 기술 보다
UX가 더 우선 순위에 있는 이 시점에서
SSO의 존재 이유와 가치는 여기에 있기 때문이다.
불과 10년전만 해도 수 많은
포털 사이트의 접근 권한을 얻기 위해
혹은 서비스를 이용하기 위해
계정을 등록해야만 했고
아이디와 비밀번호를 관리해야 했으며
잘 이용하지 않는 서비스의 경우
아이디 또는 비밀 번호를 항상 찾아야만 하는 번거로움이 있었다.
이는 이용자 입장에서 매우 치명적이다.
물론 현재에도 이러한 점은 빈번하게 나타나지만,
비교적 최근 IT업계에서의 생산성의 향상으로
한 기업에서 여러가지 서비스를 개발할 수 있게 되었고
이 것이 플랫폼으로 나타남으로써
이런 권한들을 부여하기 위한 솔루션이 필요했을 것 이다.
만약 SSO가 없었다면,
같은 플랫폼 내부에서 앱을 이동할 때 마다
매번 아이디와 비밀번호를 입력해야만 했을 것이다.
단점에 대해 살펴보자.
첫 번째,
하나의 계정으로 여러가지 앱에 접속할 수 있다는 것은
당연하게도 보안 문제가 있을 수 있다.
다만, 이 경우 추가적인 보안 과정을 추가하면
계정 보안에 대한 리스크를 줄일 수 있다.
스마트폰이 대중화되면서
OTP 생성 앱을 사용할 수 있게 됨으로써
이 부분에 대해서는
많은 부분에서 해결 되었다고 볼 수 있다.
처음 사용자 인증 과정에서 비밀 번호 대신에
OTP를 입력하게 하여 추가적인 보안 장치를 도입을 고려할 필요가 있다.
다소 번거로울 수 있으나
같은 플랫폼 내부에 여러 앱을 사용할 수 있기 때문에
추가적인 보안을 도입하는 것이 좋다.
두 번째,
일반적인 인증 시스템 보다 구현하기 복잡하다.
다만, 인증 시스템 구현에 도움을 줄 수 있는
서비스가 이미 존재하기 때문에 이러한 서비스를 이용하자.
AWS, google, MS사의 Azure와 같은
클라우드 미들웨어 서비스에 Single Sign On에 대한 기능이 포함되어 있다.
물론 전반적인 SSO의 이해가 없다면
구현 과정 또는 운영 과정에서 나타날 수 있는 리스크가 있다.
마치며 : 서비스에 SSO 도입은 꼭 필요한가?
그렇다면 이번 이야기의 마무리로
과연 내 프로젝트 혹은 나의 서비스에 SSO의 도입이
필요 할까에 대한 이야기를 해볼까 한다.
당연하게도 꼭 필요하다고 보기는 힘들다.
SSO는 일반적으로 플랫폼 서비스에 매우 잘 어울리는 기술 이다.
메일, 클라우드 서비스, 스프레드 시트와 같이
여러가지 솔루션을 보유하고 있고
이미 운용하고 있는 구글과 같은 서비스 말이다.
이 경우 SSO 도입은 필수 이지 않을까 싶다.
반대로 하나의 서비스만을 제공한다면
일반적인 아이디와 비밀번호를 입력하는 것 만으로도 충분하다.
다만, 여러가지 서비스를 개발할 계획이 있고
이를 하나의 플랫폼으로 묶어서 확장하려고 생각 한다면
미리 개발하는 것도 고려해 볼만 하다.
여기까지가 서비스에 대한 이야기 이고
가장 중요한 개발자로서 혹은 엔지니어로서는 어떠할까?
결론적으로는 알아두면 매우 좋은 기술이라고 할 수 있다.
SSO 기술은 이미 매우 대중화 되어있고
다룰 줄 안다는 것은 경력에 플러스가 될 수 있는 요인임에는 틀림 없다.
하지만,
일반적으로 개발자는 새로운 개발 보다는
유지 보수 작업에 투입되기 때문에
더 높은 레벨로 나아가고자 하는 것이 아니라면
다른 중요한 곳에 시간을 집중하는 것이 좋을지도 모른다.
[1] :
https://cloud.google.com/architecture/identity/single-sign-on?hl=ko
https://www.fortinet.com/resources/cyberglossary/single-sign-on
https://www.fortinet.com/resources/cyberglossary/single-sign-on
