SSO란 무엇일까?

오늘은 SSO에 대해서 찾아보고 공부해봤다.

 

어느 블로그가 정말 기가막히게 잘 나와 있어서 너무 감사하게도 보고 참고하게 되었다.

참조한 블로그는 아래 URL로 남겨두겠다.

https://gruuuuu.github.io/security/ssofriends/

아주 기가막힌 정리 글에 더욱 쉽고 빠르게 이해할 수 있었다.

 

그 블로그를 보며 내가 다시한번 정리하는 느낌으로 블로그를 작성해보고자 한다.

 

SSO란?

SSO는 Single Sign-On의 약자로써 "통합 인증"을 의미한다.

한번의 로그인을 통해 여러개의 사이트에 접속이 가능한데, 결국 한 페이지에서 로그인 하면 다른 페이지에 로그인 없이 사용자 정보를 가질 수 있도록 하는 것이다.

한 곳에 인증이 완료되면 그 인증정보를 담아 다른 페이지로 이동시켜 그 페이지도 인증이 되도록 하는 것이다.

 

장점   - 다양한 인증기술의 안정화   - 중앙 관리 가능      - 업무 단순화 및 표준화      - 보안 기능의 강화   - 여러개의 계정을 몰라도 된다.(하나면 뚝딱한다)   - 스비스별 인증시스템이 필요하지 않다.   - 하나의 계정으로 여러 시스템에 대한 사용자의 접근 관리가      가능하다.

단점   - 하나의 인증이 여러개의 정보를 제공한다. 만약 해킹을 당한다면 큰 위협이 존재한다.   - 아이디 접속권한 삭제 시 모든 서비스가 이용이 불가능해진다.   - 보안 수준이 다를 경우 보안 문제가 발생한다.

 

이제 SSO의 동작 원리를 알아보자!

 

 

동작 원리

SSO의 구현을 위한 표준은 여러개다. 하지만, 기본 패턴은 동일하며 모델을 혼용하여 구성한다.

 

2가지 모델로 구분하여 설명하겠다.

 

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

인증대행 모델은 권한을 얻으려는 서비스의 인증방식이 어려울 경우 사용된다.

대상 서비스의 인증 방식을 변경하지 않고, SSO Agent가 인증에 필요한 사용자 인증 정보를 제공 대신 전달하여 로그인을 진행한다.

 

즉, 축구선수의 계약을 에이전트에게 내 정보를 주고 계약을 대신 맡기듯 유저가 에이전트에게 대신 내 정보를 주고 이용할 서비스에게 대신 인증할 수 있도록 한다.

 

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

인증 정보 전달 모델은 웹 기반 시스템에 주로 사용되며, 통합 인증을 수행하는 위치에서 인증토큰을 발급한다. 즉, 통합 인증을 진행하는 곳을 따로 만들어 사용자의 정보를 통해 인증 토큰을 발급 받아둔다는 소리다.(물론 인증이 성공되어야 한다.) 

서비스를 사용하기 위해서 미리 발급받아둔 인증 토큰을 주고, 서비스는 그 토큰을 사용해 사용자를 인증한다.

(약간 JWT같다라는 생각을 여기서부터 하기 시작했다.)

 

그러면 구현은 어떻게 진행될까?

 

구현 방식

인증서버를 거친 사용자의 정보에 대한 "유효성"을 확인해야 한다. 이 "유효성"은 어떻게 확인해야 할까?

위에 얘기한 JWT를 사용해 유효성을 확인하는 것을 예시로 들어보자.

클라이언트의 A서비스(A) 로그인 시도 -> A는 인증서버로 해당 요청 Redirect(인증서버는 IDP로 IDentity Provider) -> 인증서버(IDP)는 클라이언트에게 Login Page로 인증할 수 있도록 제공 -> 사용자 로그인 진행 -> 인증 과정을 통해 발급받은 JWT를 A로 전달 -> A는 Access Token 확인 후 올바르면 클라이언트 로그인 허용

보기만 해도 귀찮다. 그래도 해야지 어쩌겠나..

이렇게 Access Token처럼 유효성을 확인할 수 있는 무언가가 존재하는데,,, 그 종류를 이제 알아보자.

 

1. SAML(Security Assertion Markup Language)

일단 마지막에 ML이 들어간 것 보면 XML형식이지 않을까? 싶었다. 결국 XML형식이 맞았다. 나는 XML형식을 별로 좋아하진 않는다.

인증정보 제공자와 서비스 제공자 간 인증 및 인가 데이터 교환을 위한 XML기반 표준 데이터 포맷

이라고 하는데 도대체 어떻게 인증 및 인가 데이터를 교환하나 혹시 정보들을 다 포함해 전송하면 보안에 좋지 않을 것 같았다.

하지만, 인증정보를 담은 후 암호화 하여 내용 도출을 하지 못하도록 막았다고 한다. 이를 Assertion이라고 부른다.

Assertion은 공급자의 이름, 발행일 및 만료일 등 정보를 담고 있다.

 

인증은 어떻게 진행될까?

 

1-1. SAML의 인증 방법

총 3가지의 역할이 존재한다.

• User : 인증을 원하는 사용자
• Identity Provider(IDP) : 인증 정보 제공자
• Service Provider(SP) : 서비스 제공자

1. 서비스 요청(User -> SP)
   - SP는 유저의 인증 확인을 진행한다.
2. SSO 서비스 이동(SP -> User)
   - 인증되지 않은 사용자이기 때문에 정보를 담아 보내라는 SAML Request를 생성하여 유저에게 전송한다.
3. SSO 서비스 요청(User -> IDP, 이 때 User는 Redirect하여 SAML Request와 함께 전송한다.)
   - IDP는 SAML Request를 받아 인증을 진행하는데, ID/PW든 뭐든 원래 인증하던대로 인증시킨다.
4. SAML Response(IDP -> User)
   - IDP에서 인증을 성공하면 SAML Response를 만들어 다시 User로 보내준다.
   - 이 때, SAML Response에 Assertion도 포함된다!!!!!!!!!!!!!!!
   - 또한, 브라우저에 쿠키도 굽고 세션도 남겨둔다. SAML Response 정보들은 브라우저에 캐싱된다.
5. SAML Response 전송(User -> SP)
   - SP의 ACS(Assertion Consumer Service)에서 SAML Response를 검증한다.
   - SP로 보낼 때 SP로 직접 보내는 것이 아닌 ACS URL로 Redirect 시킨다.
6. 서비스 응답(SP -> User)
   - ACS에서 받은 검증이 유효하다면 요청한 Service로 User를 이동시킨다.

꽤나 복잡하지만 인증은 굉장히 중요하기 때문에 절차가 복잡해도 해야하지 않겠는가?

 

이렇게 첫 인증이 완료되면 다른 페이지는 어떻게 인증시킬까?

위의 2번의 SSO 서비스 이동을 통해 User로 돌아왔을 때, 4번에서 저장해둔 SAML Response를 사용해 다시 SP로 넘겨줘 인증받을 수 있도록 한다.

 

하지만, SAML은 XML 형식이기에 브라우저에서만 사용할 수 있다는 단점을 가지고 있다. 즉, 모바일 혹은 Native App에서는 사용이 불가능하다는 것이다.

 

하지만 사람들은 이를 해결하기 위해 다른 방법도 구현해 두었다.

바로

 

 

2. OAUTH 2.0

이는 카카오/페이스북/구글 등 외부 로그인이 필요할 경우 사용했던 기억이 있다. 꽤나 정보 받아오는데 고통스러웠다.

이는 Authorization을 위한 개방형 표준 프로토콜로써 내가 소유하고 있는 권한을 제공하는 방법이다.

 Authorization VS Authentication

1. Authorization : '인가', 즉 나는 어떠한 권한을 소유하고 있는지 알려줄 수 있는 정보를 의미

2. Authentication : '인증', 즉 나는 누구인가를 알려줄 수 있는 정보를 의미

 

즉, 사용자의 동의를 받아 페이스북의 중요한 정보(계정)를 사용하려는 서비스에 공유하지 않고도 페이스북 자원에 접근이 가능하다는 말이다.

동의만 하면 니 정보빼고 사용할 수 있는거 다 사용 가능하다는 말임.

이는 왜 SAML의 단점을 해결하기 위한 것이냐면, XML기반이 아닌 JSON기반의 인증 방식이기 때문이다.

당연히 모바일과 Native App도 사용이 가능하다.

 

이는 어떻게 인증할까?

 

2-1. OAUTH 2.0의 인증 방법

간단하다. 바로 JWT와 굉장히 비슷하지만, 유저의 정보를 암호화해서 보내는 것이 아닌 위에 설명한 것 처럼 "권한"만 담고있는 Access Token을 활용한다.

이 Access Token은 SAML의 Assertion과 굉장히 비슷하다. 하지만, 인증에 대한 정보는 갖고있지 않고, 권한에 대한 허가 기능만 담고 있기 때문에 분명히 다르다고 얘기할 수 있다.

 

만약!!!!!!!!

제 3의 앱에서 Access Token을 요청하였을 때 해당 Token을 받을 Redirect URL도 필요하다.

그런데, Redirect URL을 어느 해커가 따로 지정한다면 얼마나 괴롭힘당할지 상상만해도 끔찍하다.

이를 해결하기 위해 제 3의 앱에 Redirect URL을 미리 지정하여 다른 URL로 Redirect를 절대로 못하게 하는 방법을 통해 보안성을 향상시킬 수 있다.(위에 적어둔 블로그를 살펴보면 그림으로 잘 설명되어 있다.)

 

또한, Access Token이 탈취되어도 유효기간이 존재하기 때문에 만료되면 사용할 수 없도록 생성한다. 하지만, 원래 사용하던 사람의 Access Token이 만료된다면.. 재발급이 필요한데, 이 때 사용하는 Token이 Refresh Token이다.

절대 JWT와 비슷해 보이지만, 담고있는 정보가 전혀 다르다.

 

인증하는 방법은 JWT와 동일하기 때문에 생략하겠다.

 

그러면 Authorization 뿐만 아니라 Authentication 도 가능하도록 하는 방법도 구현해 두었더라.

바로

 

 

3. OIDC(OpenID Connect)

참 잘만든다. 이는 OAUTH 2.0을 이용하여 만들어진 인증 레이어로, 내가 누군지 알려주기 위해 ID Token을 추가한다.

이게 진짜 JWT와 같다. 왜냐하면, 내 정보(ID든 뭐든 내 정보면 다)까지 포함되어 있는 OAUTH의 Access Token이기 때문이다.

 

인증 방법은 OAUTH와 동일하기 때문에 생략하겠다.

 

 

결론

SSO를 통해 사람이 정말 살기 편하게 만드는 것 같다. 물론 다른 것들도 다 편한데 이건 진짜 모든 게임이든 포털사이트는 싸악 다 하나의 계정으로 만들어 버렸으면 좋겠다는 생각이다. 개인용 SSO를 만들어 미리 저장해둔 내 컴퓨터 계정을 통해 모든 사이트들에 들어가기만 하면 자동으로 로그인 되어있으면 좋겠다 진짜.

나름 인증방법이다보니 굉장히 어렵다고 생각했지만, 참고한 블로그의 주인님 덕분에 엄청 쉽게 이해할 수 있었다,

감사합니다.