맨위로가기

통합 인증

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

통합 인증(SSO, Single Sign-On)은 한 번의 로그인으로 여러 시스템과 애플리케이션에 접근할 수 있도록 하는 기술이다. 사용자, 관리자, 개발자 모두에게 편의성과 보안 측면에서 이점을 제공하며, 여러 개의 ID와 비밀번호를 관리해야 하는 번거로움을 줄여준다. SSO는 사용자 인증 정보를 중앙 집중식으로 관리하여 보안을 강화하고, 관리 효율성을 높인다. 하지만, 보안 취약성 및 개인 정보 보호 문제, 그리고 인증 시스템의 가용성에 대한 의존도가 높다는 단점도 존재한다.

더 읽어볼만한 페이지

  • 컴퓨터 접근 제어 - 로그인
    로그인은 특정 페이지, 웹사이트 또는 응용 프로그램에 접근하기 위해 사용자 이름과 암호를 입력하여 시스템에 접근하는 절차이며, 1960년대 시분할 시스템과 1970년대 BBS에서 사용되기 시작했다.
  • 컴퓨터 접근 제어 - SIM 카드
    SIM 카드는 이동통신 장치에서 가입자 정보를 저장하고 네트워크를 인증하는 스마트 카드로, 가입자 식별 정보, 인증 정보, 전화번호부 등을 저장하며, 최근에는 내장형 eSIM으로 발전하고 있다.
  • 보안 - 금고
    금고는 현금, 귀중품, 중요 문서 등을 도난, 화재, 외부 위협으로부터 안전하게 보관하기 위한 잠금장치가 있는 견고한 상자 또는 보관 시설로, 기원전 13세기 이집트에서 기원하여 다양한 재료와 잠금 방식으로 발전해왔으며, 내화 금고, 방도 금고, 대여 금고 등 다양한 종류와 UL, EN 등의 국제적인 표준에 따른 성능 등급이 존재한다.
  • 보안 - 경비원
    경비원은 시설 및 인력을 보호하고 출입을 통제하며 순찰, 위험 감지 및 보고 등의 업무를 수행하는 직업으로, 화재, 도난, 침입 등으로부터 보호하며 방문객 안내, 배달물 접수 등의 부가적인 서비스를 제공하기도 한다.
통합 인증
개요
유형인증 방식
설명한 번의 로그인으로 여러 시스템 접근 권한을 얻는 인증 방식
약칭SSO
기술적 특징
주요 목표사용자 인증 관리 간소화
접근 제어 효율성 향상
보안 강화
인증 방식
일반적인 방식쿠키 기반 인증
토큰 기반 인증 (OAuth, OpenID Connect)
SAML (Security Assertion Markup Language)
Kerberos
장점
사용자 측면여러 웹사이트에 대한 로그인 정보를 기억할 필요가 없음
생산성 향상
관리자 측면사용자 계정 관리 용이
보안 정책 중앙 집중 관리
단점
보안 취약점SSO 시스템 자체의 보안 취약점 발생 시 전체 시스템에 영향
단일 실패 지점 (Single Point of Failure)
활용 분야
예시기업 내부 시스템 접근
클라우드 서비스 접근
웹사이트 로그인
관련 기술
관련 기술LDAP (Lightweight Directory Access Protocol)
Active Directory
OAuth
OpenID Connect
SAML
보안 고려 사항
주요 고려 사항강력한 인증 메커니즘 적용 (다단계 인증)
SSO 시스템 보안 강화
접근 권한 관리 철저
추가 정보
참고사용자 경험 향상 및 보안 강화를 위해 SSO 도입 시 다양한 요소 고려 필요

2. 장점

통합 인증(SSO)은 사용자, 관리자, 개발자 모두에게 다양한 이점을 제공하며, 보안 측면에서도 긍정적인 효과를 가져온다.

== 사용자 측면 ==

통합 인증(SSO)을 사용하면 여러 개의 ID와 비밀번호를 관리할 필요 없이 한 번의 로그인으로 다양한 시스템과 애플리케이션을 이용할 수 있다.[5] 이는 사용자에게 다음과 같은 장점을 제공한다.


  • 서로 다른 사용자 이름과 비밀번호 조합으로 인한 비밀번호 피로를 줄일 수 있다.[5]
  • 동일한 ID에 대해 비밀번호를 반복 입력하는 시간을 절약할 수 있다.[5]
  • 비밀번호 관련 IT 헬프 데스크 요청 감소로, 관련 비용을 절감 할 수 있다.[6]
  • 사용자 비밀번호가 외부에 저장되거나 관리되지 않으므로, 타사 사이트에 대한 접근 위험("연합 인증")을 완화한다.[5]


사용자는 한 벌의 ID와 비밀번호만 기억하면 되므로, 여러 개의 ID와 비밀번호를 기억하고 관리해야 하는 부담을 덜 수 있다.

== 관리자 측면 ==

통합 인증(SSO)을 통해 관리자는 다음과 같은 이점을 얻을 수 있다.[5]

  • SSO 관련 작업은 다른 관리 작업에 사용되는 것과 동일한 도구를 사용하여 정상적인 유지 관리의 일부로 투명하게 수행되므로 관리가 용이하다.
  • 모든 네트워크 관리 정보는 단일 저장소에 저장되므로, 각 사용자의 권한 및 특권에 대한 단일 권한 목록을 통해 관리자는 사용자의 권한을 변경하고 그 결과가 네트워크 전체에 전파될 것임을 알 수 있다.
  • 사용자는 더 이상 여러 번의 로그온에 얽매이지 않으며 네트워크 리소스에 액세스하기 위해 여러 비밀번호를 기억할 필요가 없어 사용자 생산성이 향상된다. 이는 잊어버린 비밀번호에 대한 요청을 덜 처리해야 하는 헬프 데스크 담당자에게도 도움이 된다.
  • 여러 비밀번호를 제거하면 사용자가 비밀번호를 적어두는 보안 침해의 일반적인 원인도 줄어든다. 네트워크 관리 정보의 통합으로 인해 관리자는 사용자의 계정을 비활성화할 때 해당 계정이 완전히 비활성화되었음을 확실히 알 수 있다.
  • 서로 다른 네트워크를 결합하여 관리 노력을 통합하여 관리 모범 사례와 기업 보안 정책이 일관되게 시행되도록 할 수 있다.


== 개발자 측면 ==

시스템 관리자나 애플리케이션 개발자는 비밀번호 등 사용자 인증 정보를 일원화하여 관리함으로써, 여러 사용자 인증 정보를 관리하거나 애플리케이션별로 사용자 인증 기능을 개발해야 하는 부담에서 벗어날 수 있다.

== 보안 측면 ==

SSO는 사용자 비밀번호가 외부에 저장되거나 관리되지 않으므로, 타사 사이트에 대한 접근 위험("연합 인증")을 완화한다.[5] 더 나아가, 모든 네트워크 관리 정보가 단일 저장소에 저장되므로 관리자는 사용자의 권한을 쉽게 변경하고 네트워크 전체에 적용할 수 있다.

SSO는 여러 비밀번호를 제거하여 사용자가 비밀번호를 적어두는 일반적인 보안 침해 원인을 줄인다. 네트워크 관리 정보의 통합으로 관리자는 사용자의 계정을 비활성화할 때 해당 계정이 완전히 비활성화되었음을 확신할 수 있다. 서로 다른 네트워크를 결합하여 관리 노력을 통합하고, 관리 모범 사례와 기업 보안 정책이 일관되게 시행되도록 할 수 있다.

2. 1. 사용자 측면

통합 인증(SSO)을 사용하면 여러 개의 ID와 비밀번호를 관리할 필요 없이 한 번의 로그인으로 다양한 시스템과 애플리케이션을 이용할 수 있다.[5] 이는 사용자에게 다음과 같은 장점을 제공한다.

  • 서로 다른 사용자 이름과 비밀번호 조합으로 인한 비밀번호 피로를 줄일 수 있다.[5]
  • 동일한 ID에 대해 비밀번호를 반복 입력하는 시간을 절약할 수 있다.[5]
  • 비밀번호 관련 IT 헬프 데스크 요청 감소로, 관련 비용을 절감 할 수 있다.[6]
  • 사용자 비밀번호가 외부에 저장되거나 관리되지 않으므로, 타사 사이트에 대한 접근 위험("연합 인증")을 완화한다.[5]


사용자는 한 벌의 ID와 비밀번호만 기억하면 되므로, 여러 개의 ID와 비밀번호를 기억하고 관리해야 하는 부담을 덜 수 있다.

2. 2. 관리자 측면

통합 인증(SSO)을 통해 관리자는 다음과 같은 이점을 얻을 수 있다.[5]

  • 서로 다른 사용자 이름과 비밀번호 조합으로 인한 비밀번호 피로를 줄일 수 있다.
  • 동일한 신원에 대해 비밀번호를 다시 입력하는 데 소요되는 시간을 줄일 수 있다.[5]
  • 비밀번호 관련 IT 헬프 데스크 호출 횟수를 줄여 IT 비용을 절감할 수 있다.[6]
  • SSO 관련 작업은 다른 관리 작업에 사용되는 것과 동일한 도구를 사용하여 정상적인 유지 관리의 일부로 투명하게 수행되므로 관리가 용이하다.
  • 모든 네트워크 관리 정보는 단일 저장소에 저장되므로, 각 사용자의 권한 및 특권에 대한 단일 권한 목록을 통해 관리자는 사용자의 권한을 변경하고 그 결과가 네트워크 전체에 전파될 것임을 알 수 있다.
  • 사용자는 더 이상 여러 번의 로그온에 얽매이지 않으며 네트워크 리소스에 액세스하기 위해 여러 비밀번호를 기억할 필요가 없어 사용자 생산성이 향상된다. 이는 잊어버린 비밀번호에 대한 요청을 덜 처리해야 하는 헬프 데스크 담당자에게도 도움이 된다.
  • 여러 비밀번호를 제거하면 사용자가 비밀번호를 적어두는 보안 침해의 일반적인 원인도 줄어든다. 네트워크 관리 정보의 통합으로 인해 관리자는 사용자의 계정을 비활성화할 때 해당 계정이 완전히 비활성화되었음을 확실히 알 수 있다.
  • 서로 다른 네트워크를 결합하여 관리 노력을 통합하여 관리 모범 사례와 기업 보안 정책이 일관되게 시행되도록 할 수 있다.


SSO는 다른 모든 애플리케이션과 시스템이 인증 목적으로 사용하는 중앙 집중식 인증 서버를 공유하고 사용자가 한 번 이상 자격 증명을 적극적으로 입력할 필요가 없도록 하는 기술과 결합한다. 사용자가 특정 컴퓨터에 로그인한 후, 그룹웨어 등의 애플리케이션을 이용할 경우, 다시 로그인하여 다른 서버 상의 애플리케이션을 사용해야 할 때마다 또 다시 로그인을 해야 하는 상황에서는, 여러 개의 ID와 비밀번호를 관리해야 한다. 싱글 사인온을 도입하면 사용자는 한 벌의 ID와 비밀번호만 기억하면 모든 기능을 사용할 수 있다.

또한, 시스템 관리자나 애플리케이션 개발자는 비밀번호 등 사용자 인증 정보를 일원화하여 관리함으로써, 여러 사용자 인증 정보를 관리하거나 애플리케이션별로 사용자 인증 기능을 개발해야 하는 부담에서 벗어날 수 있다.

2. 3. 개발자 측면

통합 인증(SSO)을 도입하면 사용자는 한 벌의 ID와 비밀번호만 기억하면 모든 기능을 사용할 수 있다. 사용자는 더 이상 여러 번의 로그온에 얽매이지 않으며 네트워크 리소스에 액세스하기 위해 여러 비밀번호를 기억할 필요도 없다.[5] 이는 잊어버린 비밀번호에 대한 요청을 덜 처리해야 하는 헬프 데스크 담당자에게도 도움이 된다.[6] 여러 비밀번호를 제거하면 사용자가 비밀번호를 적어두는 보안 침해의 일반적인 원인도 줄어든다.[5]

시스템 관리자나 애플리케이션 개발자는 비밀번호 등 사용자 인증 정보를 일원화하여 관리함으로써, 여러 사용자 인증 정보를 관리하거나 애플리케이션별로 사용자 인증 기능을 개발해야 하는 부담에서 벗어날 수 있다. SSO 관련 작업은 다른 관리 작업에 사용되는 것과 동일한 도구를 사용하여 정상적인 유지 관리의 일부로 투명하게 수행된다. 모든 네트워크 관리 정보는 단일 저장소에 저장되므로, 각 사용자의 권한 및 특권에 대한 단일 권한 목록이 생긴다. 이를 통해 관리자는 사용자의 권한을 변경하고 그 결과가 네트워크 전체에 전파될 것임을 알 수 있다. 네트워크 관리 정보의 통합으로 인해 관리자는 사용자의 계정을 비활성화할 때 해당 계정이 완전히 비활성화되었음을 확실히 알 수 있다. 서로 다른 네트워크를 결합하여 관리 노력을 통합하여 관리 모범 사례와 기업 보안 정책이 일관되게 시행되도록 할 수 있다.

SSO는 다른 모든 애플리케이션과 시스템이 인증 목적으로 사용하는 중앙 집중식 인증 서버를 공유하고 사용자가 한 번 이상 자격 증명을 적극적으로 입력할 필요가 없도록 하는 기술과 결합한다. 사용자가 특정 컴퓨터에 로그인한 후, 그룹웨어 등의 애플리케이션을 이용할 경우, 다시 로그인하여 다른 서버 상의 애플리케이션을 사용해야 할 때마다 또 다시 로그인을 해야 하는 상황에서는, 여러 개의 ID와 비밀번호를 관리해야 한다.

2. 4. 보안 측면

통합 인증(SSO)은 여러 애플리케이션 및 시스템에서 사용자가 한 번의 로그인으로 인증을 받을 수 있도록 하는 중앙 집중식 인증 서버를 공유하는 기술이다.[5] 사용자는 한 번의 로그인으로 여러 서비스를 이용할 수 있어 편리하며, 여러 개의 ID와 비밀번호를 관리해야 하는 부담을 줄여준다. 이는 비밀번호 피로를 감소시키고, 동일한 신원에 대해 비밀번호를 다시 입력하는 데 소요되는 시간을 줄여준다.[5] 또한, 비밀번호 관련 IT 헬프 데스크 호출 횟수를 줄여 IT 비용 절감에도 기여한다.[6]

SSO는 사용자 비밀번호가 외부에 저장되거나 관리되지 않으므로, 타사 사이트에 대한 접근 위험("연합 인증")을 완화한다.[5] 더 나아가, 모든 네트워크 관리 정보가 단일 저장소에 저장되므로 관리자는 사용자의 권한을 쉽게 변경하고 네트워크 전체에 적용할 수 있다. 사용자는 여러 번 로그온하거나 여러 비밀번호를 기억할 필요가 없어 생산성이 향상되며, 헬프 데스크는 잊어버린 비밀번호 관련 요청을 덜 처리해도 된다.

SSO는 여러 비밀번호를 제거하여 사용자가 비밀번호를 적어두는 일반적인 보안 침해 원인을 줄인다. 네트워크 관리 정보의 통합으로 관리자는 사용자의 계정을 비활성화할 때 해당 계정이 완전히 비활성화되었음을 확신할 수 있다. 서로 다른 네트워크를 결합하여 관리 노력을 통합하고, 관리 모범 사례와 기업 보안 정책이 일관되게 시행되도록 할 수 있다. 시스템 관리자와 애플리케이션 개발자는 사용자 인증 정보를 일원화하여 관리함으로써 여러 사용자 인증 정보를 관리하거나 애플리케이션별로 사용자 인증 기능을 개발해야 하는 부담에서 벗어날 수 있다.

3. 단점 및 비판

일부에서는 "단일 로그인"(SSO)이 기업 내에서 서로 다른 수준의 보안 접근에 대한 필요성을 해결하는 데 실용적이지 않다는 점을 반영하여 "축소된 로그인"(RSO)이라는 용어를 사용하기도 한다.[7] 이 경우 둘 이상의 인증 서버가 필요할 수 있다.[7]

단일 로그인은 사용자가 처음 인증되면 많은 리소스에 대한 접근을 제공하므로 ("성으로 가는 열쇠"), 자격 증명이 다른 사람에게 노출되어 오용될 경우 부정적인 영향이 커진다.[7] 따라서 단일 로그인은 사용자 자격 증명 보호에 대한 관심이 높아져야 하며, 스마트 카드 및 일회용 패스워드 토큰과 같은 강력한 인증 방법과 결합하는 것이 이상적이다.[7]

단일 로그인은 또한 가용성이 높은 인증 시스템에 대한 의존도를 높인다.[8] 해당 시스템의 가용성이 손실되면 SSO에 통합된 모든 시스템에 대한 접근이 거부될 수 있다.[8] SSO는 시스템 운영을 유지하기 위해 세션 페일오버 기능을 갖도록 구성할 수 있지만,[8] 시스템 장애의 위험은 접근이 보장되어야 하는 보안 또는 공장 현장 시스템과 같은 시스템에 대해 단일 로그인을 바람직하지 않게 만들 수 있다.

페이스북과 같은 소셜 네트워킹 서비스를 활용하는 단일 로그인 기술의 사용은 생산성상의 이유로 소셜 미디어 사이트를 차단하는 도서관, 학교 또는 직장에서 타사 웹사이트를 사용할 수 없게 만들 수 있다.[9] 또한 중국과 "만리 방화벽"과 같은 활발한 검열 체제를 가진 국가에서도 어려움을 야기할 수 있는데, 이 경우 타사 웹사이트는 적극적으로 검열되지 않더라도 사용자의 소셜 로그인이 차단되면 효과적으로 차단된다.[9][10]

요구되는 보안 수준이 다른 웹 서버에 동일한 사용자 ID와 비밀번호 조합을 입력하게 하는 것은 적절하지 않은 경우가 있다.

3. 1. 보안 취약성

2012년 3월, 한 연구 논문은 소셜 로그인 메커니즘의 보안에 대한 광범위한 연구를 보고했다. 연구진은 OpenID (구글 ID 및 페이팔 액세스 포함), 페이스북, Janrain, Freelancer, FarmVille, Sears.com과 같은 유명 ID 제공업체 및 의존 당사자 웹사이트에서 8가지 심각한 논리적 결함을 발견했다. 연구원들이 결함 발견에 대한 공개 발표 전에 ID 제공업체와 의존 당사자 웹사이트에 알렸기 때문에 취약성이 수정되었으며, 보안 침해는 보고되지 않았다.[11][12]

2014년 5월, 은밀한 리디렉션이라는 취약성이 공개되었다.[13] 싱가포르 난양 공과 대학교의 수학 박사 과정 학생인 왕징에 의해 "OAuth 2.0 및 OpenID 관련 은밀한 리디렉션 취약성"으로 처음 보고되었다.[14][15][16] 거의 모든 싱글 사인온 프로토콜이 영향을 받는다. 은밀한 리디렉션은 XSS 또는 오픈 리디렉션에 취약한 타사 클라이언트를 악용한다.[17]

2020년 12월, 연합 인증 시스템의 결함이 2020년 미국 연방 정부 데이터 유출 동안 공격자에 의해 악용된 것으로 밝혀졌다.[18][19]

싱글 사인온이 작동하는 방식 때문에, 토큰은 HttpOnly 쿠키 플래그로 보호될 수 없으며, 로그아웃된 웹사이트에 XSS 취약점이 있는 경우 공격자가 훔쳐 세션 하이재킹을 수행할 수 있다. 또 다른 보안 문제는 SSO에 사용된 세션이 도난당한 경우 (SSO 토큰과 달리 HttpOnly 쿠키 플래그로 보호 가능) 공격자가 SSO 시스템을 사용하는 모든 웹사이트에 액세스할 수 있다는 것이다.[20] 요구되는 보안 수준이 다른 웹 서버에 동일한 사용자 ID와 비밀번호 조합을 입력하게 하는 것은 적절하지 않은 경우가 있다.

3. 2. 개인 정보 보호 문제

단일 로그인(SSO)은 원래 Kerberos와 SAML에서 구현되었을 때 사용자가 방문하는 각 새로운 리소스에 개인 정보를 공개하는 것에 대한 어떠한 선택권도 제공하지 않았다.[21] 이는 Kerberos가 발명된 MIT나 모든 리소스가 내부 사이트인 주요 기업과 같은 단일 기업 내에서는 충분히 잘 작동했다. 그러나 Active Directory Federation Services와 같은 연합 서비스가 확산되면서 사용자의 개인 정보는 사용자의 데이터를 수집한 기업의 통제를 받지 않는 제휴 사이트로 전송되었다. 현재 개인 정보 보호 규정이 GDPR과 같은 법률로 인해 강화됨에 따라 OpenID Connect와 같은 새로운 방법이 더 매력적으로 보이기 시작했다. 예를 들어 Kerberos의 개발자인 MIT는 현재 OpenID Connect를 지원한다.[21]

이론적으로는 싱글 사인온이 이메일 주소와 같은 식별 정보를 신뢰 당사자(자격 증명 소비자)에게 공개하지 않고 작동할 수 있지만, 많은 자격 증명 제공자는 사용자가 신뢰 당사자에게 전달되는 정보를 구성하는 것을 허용하지 않는다. 2019년 기준으로 구글과 페이스북 로그인은 사용자가 이메일 주소를 자격 증명 소비자와 공유할 필요가 없다. iOS 13에 도입된 "Apple로 로그인"은 사용자가 새로운 서비스에 가입할 때마다 고유한 중계 이메일 주소를 요청할 수 있도록 하여 자격 증명 소비자가 계정을 연결할 가능성을 줄인다.[22]

요구되는 보안 수준이 다른 웹 서버에 동일한 사용자 ID와 비밀번호 조합을 입력하게 하는 것은 적절하지 않은 경우가 있다.

3. 3. 기타 문제점

일부에서는 "단일 로그인"(SSO)이 기업 내에서 서로 다른 수준의 보안 접근에 대한 필요성을 해결하는 데 실용적이지 않다는 점을 반영하여 "축소된 로그인"(RSO)이라는 용어를 사용하기도 한다.[7] 이 경우 둘 이상의 인증 서버가 필요할 수 있다.[7]

단일 로그인은 사용자가 처음 인증되면 많은 리소스에 대한 접근을 제공하므로 ("성으로 가는 열쇠"), 자격 증명이 다른 사람에게 노출되어 오용될 경우 부정적인 영향이 커진다.[7] 따라서 단일 로그인은 사용자 자격 증명 보호에 대한 관심이 높아져야 하며, 스마트 카드 및 일회용 패스워드 토큰과 같은 강력한 인증 방법과 결합하는 것이 이상적이다.[7]

단일 로그인은 또한 가용성이 높은 인증 시스템에 대한 의존도를 높인다.[8] 해당 시스템의 가용성이 손실되면 SSO에 통합된 모든 시스템에 대한 접근이 거부될 수 있다.[8] SSO는 시스템 운영을 유지하기 위해 세션 페일오버 기능을 갖도록 구성할 수 있지만,[8] 시스템 장애의 위험은 접근이 보장되어야 하는 보안 또는 공장 현장 시스템과 같은 시스템에 대해 단일 로그인을 바람직하지 않게 만들 수 있다.

페이스북과 같은 소셜 네트워킹 서비스를 활용하는 단일 로그인 기술의 사용은 생산성상의 이유로 소셜 미디어 사이트를 차단하는 도서관, 학교 또는 직장에서 타사 웹사이트를 사용할 수 없게 만들 수 있다.[9] 또한 중국과 "만리 방화벽"과 같은 활발한 검열 체제를 가진 국가에서도 어려움을 야기할 수 있는데, 이 경우 타사 웹사이트는 적극적으로 검열되지 않더라도 사용자의 소셜 로그인이 차단되면 효과적으로 차단된다.[9][10]

요구되는 보안 수준이 다른 웹 서버에 동일한 사용자 ID와 비밀번호 조합을 입력하게 하는 것은 적절하지 않은 경우가 있다.

4. 구현 방식

최신 형태의 싱글 사인온 인증은 모바일 기기를 접근 인증 수단으로 사용하여 개발되었다. 사용자들은 OpenID Connect 및 SAML[24]을 포함한 인증 방식을 사용하여 모바일 기기를 건물 출입 통제 시스템 및 컴퓨터 시스템과 같은 여러 시스템에 자동으로 로그인할 수 있으며, 접근 서버에 모바일 기기를 식별하기 위해 사용되는 X.509 ITU-T 암호화 인증서와 함께 사용된다.

모바일 기기는 "당신이 가진 것"이며, 이는 "당신이 아는 것"인 비밀번호나 "당신인 것"인 생체 인식(지문, 망막 스캔, 얼굴 인식 등)과 대조된다. 보안 전문가들은 최상의 보호를 위해 이 세 가지 요소 중 최소 두 가지(다단계 인증)를 사용할 것을 권장한다.

인트라넷 내 파일 서버에 대해 싱글 사인온을 실현하는 방식에는 Kerberos 인증이 있으며, 이는 Windows 네트워크의 "통합 Windows 인증"에도 구현되어 있다.

인트라넷 내 웹 서버에 대해 싱글 사인온을 실현하는 방식에는 다음과 같은 것이 있다[28]。


  • 리버스 프록시형: 리버스 프록시를 개입시켜 처리하는 방식. 디지털 인증서를 이용하는 경우도 있다.
  • 에이전트형: 대상이 되는 웹 서버에 "에이전트"라고 불리는 전용 소프트웨어를 도입하여, 에이전트에 의한 처리를 디렉터리 서비스에서 통합 관리하는 방식. HTTP 쿠키가 이용되고 있다.


연합(federated) 아이덴티티로 복수의 웹 서버에 대해 "Reduced sign-on"을 실현하는 방식에는 다음과 같은 것이 있다.

  • SAML에 기초한 아이덴티티 프로바이더(IdP): SAML의 어설션에 의해 사용자 인증 결과를 전달하는 방식.
  • OpenID에 기초한 아이덴티티 프로바이더(IdP): OpenID의 ID 토큰에 의해 사용자 인증 결과를 전달하는 방식.

4. 1. 인트라넷 환경

초기 로그인은 사용자에게 자격 증명을 요구하고, Kerberos 티켓-승인 티켓(TGT)을 얻는다.[28] 이메일 클라이언트, 위키, revision-control 시스템 등 인증이 필요한 추가 소프트웨어 애플리케이션은 티켓 승인 티켓을 사용하여 서비스 티켓을 획득하여 사용자에게 자격 증명을 다시 입력하라는 메시지 없이 메일 서버/위키 서버 등에 사용자의 신원을 증명한다.[28]

Windows 환경에서 Windows 로그인은 TGT를 가져온다.[28] Active Directory 인식 애플리케이션은 서비스 티켓을 가져오므로 사용자에게 재인증하라는 메시지가 표시되지 않는다.[28]

유닉스/리눅스 환경에서 Kerberos PAM 모듈을 통한 로그인은 TGT를 가져온다.[28] Evolution, 파이어폭스, SVN과 같은 Kerberized 클라이언트 애플리케이션은 서비스 티켓을 사용하므로 사용자에게 재인증하라는 메시지가 표시되지 않는다.[28] 초기 로그인 시 사용자는 스마트 카드를 요구받으며, 추가적인 응용 소프트웨어 역시 사용자가 자격 증명을 다시 입력하라는 메시지 없이 스마트 카드를 사용한다.[28] 스마트 카드 기반의 단일 로그인(Single Sign-On)은 스마트 카드에 저장된 인증서 또는 비밀번호를 사용할 수 있다.[28]

''통합 윈도우 인증''(Integrated Windows Authentication)은 마이크로소프트 제품과 관련된 용어로, SPNEGO, Kerberos, NTLMSSP 인증 프로토콜을 SSPI 기능과 관련하여 지칭하며, 이는 마이크로소프트 윈도우 2000에 도입되어 이후 Windows NT 기반 운영 체제에 포함되었다.[28] 이 용어는 주로 마이크로소프트 인터넷 정보 서비스와 인터넷 익스플로러 간의 자동 인증 연결을 지칭하는 데 사용된다.[28] 플랫폼 간 액티브 디렉터리 통합 공급업체는 통합 윈도우 인증 패러다임을 유닉스(Mac 포함) 및 리눅스 시스템으로 확장했다.[28]

인트라넷 내 파일 서버에 대해 싱글 사인온을 실현하는 방식에는 Kerberos 인증이 있으며, 이는 Windows 네트워크의 "통합 Windows 인증"에도 구현되어 있다.[28]

인트라넷 내 웹 서버에 대해 싱글 사인온을 실현하는 방식은 다음과 같다.[28]

  • 리버스 프록시형: 리버스 프록시를 개입시켜 처리하는 방식. 디지털 인증서를 이용하는 경우도 있다.[28]
  • 에이전트형: 대상이 되는 웹 서버에 "에이전트"라고 불리는 전용 소프트웨어를 도입하여, 에이전트에 의한 처리를 디렉터리 서비스에서 통합 관리하는 방식. HTTP 쿠키가 이용되고 있다.[28]

4. 2. 인터넷 환경 (연합 ID)

Security Assertion Markup Language(SAML)는 XML 기반의 사용자 보안 정보를 SAML ID 제공자와 SAML 서비스 제공자 간에 교환하는 방식이다. SAML 2.0은 W3C XML 암호화와 서비스 제공자에서 시작된 웹 브라우저 싱글 사인온 교환을 지원한다.[23] SAML 기반 싱글 사인온에서 사용자 에이전트(일반적으로 웹 브라우저)를 사용하는 사용자를 주체라고 한다. 사용자는 SAML 서비스 제공자에 의해 보호되는 웹 리소스를 요청한다. 서비스 제공자는 사용자의 신원을 알고 싶어하며, 사용자 에이전트를 통해 SAML ID 제공자에게 인증 요청을 보낸다. ID 제공자는 사용자 자격 증명을 제공하는 주체이다. 서비스 제공자는 ID 제공자로부터의 사용자 정보를 신뢰하여 해당 서비스 또는 리소스에 대한 접근 권한을 제공한다.

최신 형태의 싱글 사인온 인증은 모바일 기기를 접근 인증 수단으로 사용하여 개발되었다. 사용자들은 OpenID Connect 및 SAML[24]을 포함한 인증 방식을 사용하여 모바일 기기를 건물 출입 통제 시스템 및 컴퓨터 시스템과 같은 여러 시스템에 자동으로 로그인할 수 있다. 이때 접근 서버에 모바일 기기를 식별하기 위해 사용되는 X.509 ITU-T 암호화 인증서가 함께 사용된다. 모바일 기기는 "당신이 가진 것"이며, 이는 "당신이 아는 것"인 비밀번호나 "당신인 것"인 생체 인식(지문, 망막 스캔, 얼굴 인식 등)과 대조된다. 보안 전문가들은 최상의 보호를 위해 이 세 가지 요소 중 최소 두 가지(다단계 인증)를 사용할 것을 권장한다.

연합(federated) 아이덴티티로 복수의 웹 서버에 대해 "Reduced sign-on"을 실현하는 방식에는 다음과 같은 것이 있다.

  • SAML에 기초한 아이덴티티 프로바이더(IdP): SAML의 어설션에 의해 사용자 인증 결과를 전달하는 방식.
  • OpenID에 기초한 아이덴티티 프로바이더(IdP): OpenID의 ID 토큰에 의해 사용자 인증 결과를 전달하는 방식.

5. 보안 고려 사항

2012년 3월, 한 연구 논문은 소셜 로그인 메커니즘의 보안에 대한 광범위한 연구 결과를 보고했다.[11] OpenID (구글 ID 및 페이팔 액세스 포함), 페이스북, Janrain 등 유명 ID 제공업체 및 의존 당사자 웹사이트에서 8가지 심각한 논리적 결함이 발견되었다.[11] 연구원들이 결함 발견을 공개 발표하기 전에 해당 업체 및 웹사이트에 알렸기 때문에 취약성은 수정되었고, 보안 침해는 보고되지 않았다.[12]

2014년 5월에는 은밀한 리디렉션이라는 취약성이 공개되었다.[13] 이는 싱가포르 난양 공과 대학교의 수학 박사 과정 학생인 왕징에 의해 "OAuth 2.0 및 OpenID 관련 은밀한 리디렉션 취약성"으로 처음 보고되었다.[14][15][16] 은밀한 리디렉션은 XSS 또는 오픈 리디렉션에 취약한 타사 클라이언트를 악용한다.[17]

2020년 12월, 연합 인증 시스템의 결함이 2020년 미국 연방 정부 데이터 유출 동안 공격자에 의해 악용된 것으로 밝혀졌다.[18][19]

싱글 사인온(SSO) 작동 방식, 즉 로그인된 웹사이트에 SSO 토큰을 얻기 위한 요청을 보내고 토큰과 함께 로그아웃된 웹사이트에 요청을 보내는 방식 때문에, 토큰은 HttpOnly 쿠키 플래그로 보호될 수 없다. 따라서 로그아웃된 웹사이트에 XSS 취약점이 있는 경우 공격자가 토큰을 훔쳐 세션 하이재킹을 수행할 수 있다. 또한 SSO에 사용된 세션이 도난당한 경우 (SSO 토큰과 달리 HttpOnly 쿠키 플래그로 보호 가능) 공격자가 SSO 시스템을 사용하는 모든 웹사이트에 접근할 수 있다는 보안 문제도 존재한다.[20]

6. 개인 정보 보호 강화 방안

Kerberos와 SAML에서 구현되었을 때 단일 로그인(SSO)은 사용자가 방문하는 각 새로운 리소스에 개인 정보를 공개하는 것에 대한 어떠한 선택권도 제공하지 않았다. 이는 Kerberos가 발명된 MIT나 모든 리소스가 내부 사이트인 주요 기업과 같은 단일 기업 내에서는 충분히 잘 작동했다. 그러나 Active Directory Federation Services와 같은 연합 서비스가 확산되면서 사용자의 개인 정보는 사용자의 데이터를 수집한 기업의 통제를 받지 않는 제휴 사이트로 전송되었다.[21] 현재 개인 정보 보호 규정이 GDPR과 같은 법률로 인해 강화됨에 따라 OpenID Connect와 같은 새로운 방법이 더 매력적으로 보이기 시작했다. 예를 들어 Kerberos의 개발자인 MIT는 현재 OpenID Connect를 지원한다.[21]

이론적으로는 싱글 사인온이 이메일 주소와 같은 식별 정보를 신뢰 당사자(자격 증명 소비자)에게 공개하지 않고 작동할 수 있지만, 많은 자격 증명 제공자는 사용자가 신뢰 당사자에게 전달되는 정보를 구성하는 것을 허용하지 않는다. 2019년 기준으로 구글과 페이스북 로그인은 사용자가 이메일 주소를 자격 증명 소비자와 공유할 필요가 없다. iOS 13에 도입된 "Apple로 로그인"은 사용자가 새로운 서비스에 가입할 때마다 고유한 중계 이메일 주소를 요청할 수 있도록 하여 자격 증명 소비자가 계정을 연결할 가능성을 줄인다.[22]

7. 대한민국 현황 및 전망

참조

[1] 웹사이트 What's the Difference b/w SSO (Single Sign On) & LDAP? https://jumpcloud.co[...] 2019-05-14
[2] 웹사이트 SSO and LDAP Authentication http://www.authentic[...] Authenticationworld.com 2014-05-23
[3] 웹사이트 OpenID versus Single-Sign-On Server http://alleged.org.u[...] alleged.org.uk 2007-08-13
[4] 웹사이트 OpenID Connect Provider - OpenID Connect Single Sign-On (SSO) - OIDC OAuth Authentication https://www.onelogin[...]
[5] 웹사이트 Single sign-on and federated authentication https://kb.iu.edu/d/[...]
[6] 웹사이트 Benefits of SSO https://www.uoguelph[...] University of Guelph 2014-05-23
[7] 웹사이트 Single Sign On Authentication http://www.authentic[...] Authenticationworld.com 2013-05-28
[8] 웹사이트 Sun GlassFish Enterprise Server v2.1.1 High Availability Administration Guide http://docs.oracle.c[...] Oracle.com 2013-05-28
[9] 뉴스 The Censorship Effect https://techcrunch.c[...] 2014-05-03
[10] 뉴스 Censorship, external authentication, and other social media lessons from China's Great Firewall https://www.techinas[...] 2013-08-12
[11] 서적 2012 IEEE Symposium on Security and Privacy
[12] 웹사이트 "OpenID: Vulnerability report, Data confusion" http://openid.net/20[...] OpenID Foundation 2012-03-14
[13] 웹사이트 Facebook, Google Users Threatened by New Security Flaw http://www.tomsguide[...] Tom's Guide 2014-05-02
[14] 웹사이트 Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID http://tetraph.com/c[...] Tetraph 2014-05-01
[15] 웹사이트 Math student detects OAuth, OpenID security vulnerability http://techxplore.co[...] Tech Xplore 2014-05-03
[16] 웹사이트 Facebook, Google Users Threatened by New Security Flaw https://news.yahoo.c[...] Yahoo 2014-05-02
[17] 웹사이트 Covert Redirect Flaw in OAuth is Not the Next Heartbleed https://community.br[...] Symantec 2014-05-03
[18] 웹사이트 VMware Flaw a Vector in SolarWinds Breach? — Krebs on Security https://krebsonsecur[...] 2020-12-19
[19] 웹사이트 Group Behind SolarWinds Hack Bypassed MFA to Access Emails at US Think Tank https://www.security[...] 2020-12-15
[20] 웹사이트 What Is Session Hijacking? https://www.netspark[...] 2019-08-22
[21] 웹사이트 OpenID Connect Authorization https://ist.mit.edu/[...]
[22] 간행물 App Makers Are Mixed on 'Sign In With Apple' https://www.wired.co[...] 2019-06-15
[23] 논문 An authentication flaw in browser-based Single Sign-On protocols: Impact and remediations https://linkinghub.e[...] 2013-03-01
[24] 뉴스 MicroStrategy's office of the future includes mobile identity and cybersecurity https://www.washingt[...] 2014-04-14
[25] 웹사이트 シングルサインオンとは https://kotobank.jp/[...] 2021-10-19
[26] 웹사이트 Decision Point for Reduced Sign-On https://www.gartner.[...] Gartner 2012-07-09
[27] 웹사이트 なぜ「シングル・サインオン」が必要なのか？ https://atmarkit.itm[...] "@IT" 2002-12-19
[28] 웹사이트 これさえ読めば基本はカンペキ！「シングルサインオン」 http://www.keyman.or[...] 키-만즈넷 2005-09-05


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com