[Server] SSO(Single Sign-On)와 소셜 로그인(Social Login)

SSO(Single Sign-On)

SSO(Single Sign-On)는 한 번의 사용자 인증으로 다수의 애플리케이션 및 웹사이트에 대한 사용자 로그인을 허용하는 통합 인증 솔루션이다. 최근 간편 로그인 또는 소셜 로그인(Social Login)이라는 이름으로 많은 어플리케이션과 웹 사이트에서 접할 수 있다.

 

SSO의 가장 큰 장점은 하나의 플랫폼에서 인증이 끝나면 그 이후 로그인과 로그아웃을 반복할 필요가 없다는 간편함이다. 이러한 간편함은 사용자 경험을 개선하는 중요한 방법 중 하나가 된다. 뿐만 아니라 서비스를 제공자도 기술적, 관리적 측면에서 아래와 같은 이점이 있다. 

• 암호 보안 강화: 하나의 강력한 비밀번호를 만들도록 권장하여 사용자의 오입력 방지와 함께 기존의 보안 관행에서 어느정도 벗어날 수 있음
• 생산성 향상: 사용자 인증 프로세스를 간소화하고 보호된 리소스에 더 쉽게 액세스할 수 있도록 지원
• 비용 절감: 사용자 암호를 검색 또는 재설정 요청을 줄여 리소스 사용 최소화
• 보안 태세 개선: 사용자당 비밀번호 수를 최소화하여 암호를 대상으로 하는 보안 이벤트의 위험 감소
• 개선된 사용자 경험: 하나의 계정으로 다수의 로그인, 로그아웃 과정 없이 여러 서비스 이용 가능

SSO는 여러 구축 모델이 있는데 대표적으로 인증 대행 모델(Delegation Model)과 인증 정보 전달 모델(Propagation Model)이 있다.

 

인증 대행 모델(Delegation Model)

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

 

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

 

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

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

 

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

 

이외에도 위 두 방식을 혼용하는 Delegation & Propagation 방식과 Web 기반 One Cookie Domain SSO 방식이 있다. SSO는 이런 모델들에 기초하여 개발된 SAML, OAuth, OIDC, Kerberos 등의 여러 유형이 있다.

SAML

SAML(Security Assertion Markup Language)은 마크업 언어인 XML을 사용하여 사용자 식별 데이터를 교환한다. SAML 기반 SSO 서비스는 애플리케이션이 사용자 보안 인증 정보를 시스템에 저장할 필요가 없으므로 더 나은 보안과 유연성을 제공한다.

1. SAML 인증을 이용하면 사용자가 앱에 접근할 때마다 SAML ID 공급자가 인증 프로세스를 전달
2. 사용자가 자격 증명(예: 비밀번호, OTP, 컨텍스트 속성)을 입력하면 ID 공급자가 확인
3. ID 공급자가 SAML 표명(assertion) 형식으로 접근 또는 거부 응답을 반환함. 인증에 성공하면 사용자에게 리소스에 대한 접근 권한을 부여하고 그렇지 않으면 권한을 거부

 

Fig 3. SAML

 

OAuth

요즘 가장 자주 보이는 방식인 OAuth(Open Authorization)는 사용자 암호를 요청하는 대신 OAuth를 이용해 암호로 보호된 데이터에 액세스할 수 있는 사용자 권한을 얻는 방식이다. API를 통해 애플리케이션 간의 신뢰 관계를 설정하며 애플리케이션은 이를 통해 설정된 프레임워크에서 인증 요청을 보내고 응답할 수 있다. OAuth는 이전에 사용되던 OAuth 1.0과 OAuth 2.0이 있다. OAuth 1.0은 아래와 같이 동작한다.

 

OAuth 1.0

Fig 4. OAuth 1.0

 

1. 소비자가 서비스 제공자에게 요청 토큰을 요청한다.
2. 서비스 제공자가 소비자에게 요청 토큰을 발급해준다.
3. 소비자가 사용자를 서비스 제공자로 이동시키며 사용자 인증을 수행한다.
4. 서비스 제공자가 사용자를 소비자로 이동시킨다.
5. 소비자가 접근 토큰을 요청한다.
6. 제공자가 접근 토큰을 발행한다.
7. 발근된 접근 토큰을 이용하여 소비자가 사용자 정보에 접근한다.

 

하지만 OAuth 1.0은 구현이 복잡하고 HMAC(keyed-hash message authentication code, hash-based message authentication code)를 통한 암호화를 하는 번거로움이 수반된다. 또한 인증토큰이 만료가 되지 않아 토큰을 만료하려면 제공자 애플리케이션의 비밀번호를 바꿔야 하는 불편함으로 인해 이를 개선한 OAuth 2.0이 등장하였다.

 

OAuth 2.0

OAuth 2.0은 기능의 단순화와 기능과 규모의 확장성 등을 지원하기 위해 만들어졌다. https를 통해 암호화를 하여 과정의 단순화 하였고 1.0에 비해 다양한 인증 방식이 제공하여 확장성을 지원할 수 있다. 또한 api서버에서 인증서버와 리소스 서버가 분리되었다.

 

Fig 5. Oauth 2.0 인증과정 - 페이코

Fig 6. OAuth 2.0 인증 프로세스(Authorization Code Grant) - 페이코

 

• 1~5 단계: 는 Authorization Code 발급 요청 URL을 통해 진행할 수 있다.
• 7~8 단계: 는 서비스에서 callback URL 을 통해 전달받은 Authorization Code를 사용하여 Access Token 요청 API를 통해 진행할 수 있다.
  8 단계에서 발급받은 Access Token은 서비스에서 자체적으로 저장, 관리해야 한다.
• 10~11 단계: 사용자의 서비스 요청 시 회원정보가 필요하다면 Access Token을 사용해 API를 호출할 수 있다.

 

인증 정보 전달 모델부터 토큰 얘기가 자꾸 언급되는데 토큰 발급과 리프레시 토큰을 이용한 갱신은 JWT(JSON Web Token)와 유사하다고 할 수 있다.

 

OIDC(OpenID)

OIDC(OpenID)는 OAuth 2.0 위에서 동작하는 얇은 ID 계층이다. OIDC는 사용자 인증을 OAuth 2.0 프로세스를 확장하여 구현한다.
OAuth 2.0과의 차이점은 OAuth가 Athorization을 포함한다면 OIDC는 Authentication에 집중한다는 점이다.

 

OpenID를 사용하면 클라이언트는 ID 토큰을 획득할 수 있다. 이 ID 토큰에는 사용자에 대한 신원 정보가 담겨있다. 액세스 토큰이 호텔 키 카드라면, ID 토큰은 주민등록증이라고 할 수 있다. 주민등록증으로 신원 확인(이름, 사진, 거주지 주소 등)을 확인할 수 있지만 호텔 객실에는 출입할 수 없을 것이다. 만약 OIDC 없이 OAuth 2.0 단독으로 사용자 리소스를 가지고 오기 위해서는 OIDC를 사용할 때의 2배의 통신을 해야한다. 따라서 OAuth을 통한 API호출이 아닌 단순 유저 인증 및 기본정보 등을 알기위해서라면 OIDC를 사용하는것이 더 좋다.

 

OIDC를 사용하는 방법은 매우 간단하다. OAuth 를 통해 Access_token을 받을 때 id_token이라는 것도 같이 전달 받는데 이 id_token을 활용하면 된다.

 

Fig 7. OIDC

 

Kerberos

Kerberos는 둘 이상의 당사자가 네트워크에서 신원을 서로 검증할 수 있는 티켓 기반 인증 시스템이다. 보안 암호화를 사용하여 서버, 클라이언트 및 키 배포 센터 간에 전송되는 식별 정보에 대한 무단 액세스를 방지한다.

 

Fig 8. Kerberos

 

결론

SSO를 이용하는 것은 기존의 인증 시스템보다 훨씬 편리하다. 하지만 SSO는 최초 인증 과정 이후 사용자가 원하는 사이트나 서버에 자유롭게 접근할 수 있다는 보안상의 허점도 존재한다. 이를 보완하기 위한 방법으로 '아무도 믿지 않는다'라는 원칙에 기반하여 사용자에 대해 철저한 신원 검증을 실시하는 제로 트러스트가 활용되고 있다.

SSO에 제로 트러스트를 대표하는 다단계 인증(MFA) 방식을 더하면 편리함을 유지하면서 보안성을 더 높일 수 있다. 예를 들어 사용자가 최초 인증을 통과한 후 신뢰할 수 없는 네트워크에서 중요 리소스에 접근하려는 경우 OTP 인증 또는 얼굴/지문 인식 등의 추가 인증 기능을 도입하는 방법도 고려될 수 있다.

 

---

참고 자료

 

https://aws.amazon.com/ko/what-is/sso/

 

http://www.coolio.so/ssosingle-sign-on-%EC%A2%85%EB%A5%98/

 

https://toma0912.tistory.com/75

 

https://support.google.com/a/answer/6262987?hl=ko 

 

https://developers.payco.com/guide/development/start

 

https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

 

https://hudi.blog/open-id/

 

https://its-fusion-blog.tistory.com/48

 

https://www.itworld.co.kr/tags/4908/ID/193849

 

https://content.rview.com/ko/blog/sso/