싱글 사인온

Single Sign-On

방법

회사가 이미 쓰는 계정으로 한 번 로그인하면 연결된 서비스를 따로 로그인하지 않고 쓰게 해 주는 방식입니다.

등장 배경

회사에서 쓰는 도구가 열두 개면 계정도 열두 개입니다. 직원은 열두 개의 비밀번호를 기억할 수 없어서 하나를 돌려쓰거나 메모장에 적어 둡니다. 그중 하나라도 밖으로 새면 나머지 열한 개가 함께 열립니다.

관리하는 쪽은 다른 방향으로 힘듭니다. 사람이 들어오면 열두 곳에 계정을 만들고, 나가면 열두 곳을 찾아가 끊어야 합니다. 그런데 실제로는 끊는 쪽이 자주 빠집니다. 퇴사자의 계정이 협업 문서 도구에 반년째 살아 있는 상황이 이렇게 생깁니다.

수아가 200명 규모 기업 고객과 상담할 때 첫 질문으로 받은 것이 이 문제였습니다. 기능이나 가격보다 "사내 계정으로 로그인이 됩니까" 가 먼저 나왔습니다. 안 된다고 답하면 그 자리에서 검토가 끝났습니다. 고객사 보안 담당자가 계정을 한 곳에서 관리할 수 없는 도구를 승인하지 않기 때문입니다.

싱글 사인온은 인증을 한 군데로 모으는 방식입니다. 인증은 누구인지 확인하는 절차를 말합니다. 각 서비스가 저마다 확인하지 않고, 회사가 정한 한 곳에 물어서 확인을 받아 옵니다.

사용 절차

붙이는 쪽이 정할 것은 많지 않고, 대신 고객사마다 반복됩니다.

  1. 신원 공급자를 확인합니다. 고객사가 이미 쓰는 계정 관리 시스템이고, 그쪽이 사람의 신원을 보증해 줍니다. 우리가 고르는 것이 아니라 고객사가 쓰는 것에 맞추는 일입니다.
  2. 규격을 고릅니다. 기업 환경에서는 SAML, 최근에 만든 서비스는 OIDC를 쓰는 경우가 많습니다. 둘 다 지원하면 고객사를 가리지 않게 됩니다.
  3. 설정을 교환합니다. 우리 쪽 주소와 고객사 쪽 인증서를 서로 등록합니다. 이 과정이 화면 몇 번의 복사·붙여넣기라 자동화해 두지 않으면 고객사마다 30분씩 들어갑니다.
  4. 사용자 정보를 맞춥니다. 신원 공급자가 보내 주는 값 중 어느 것을 이메일로 쓰고 어느 것을 이름으로 쓸지 정합니다. 고객사가 소속 그룹을 함께 보내 주면 그걸 우리 쪽 역할로 옮길 수 있습니다.
  5. 두 방향의 로그인을 모두 시험합니다. 사용자가 우리 화면에서 시작하는 경우와 고객사 포털에서 우리 서비스를 눌러 들어오는 경우입니다. 뒤쪽을 빼먹으면 실제 사용자 절반이 못 들어옵니다.
  6. 계정 생성과 해지를 연결합니다. 사람이 입사하면 계정이 생기고 퇴사하면 꺼지는 것까지 자동으로 되어야 앞서 말한 관리 문제가 풀립니다.
  7. 비상 경로를 남깁니다. 신원 공급자가 멈추면 아무도 못 들어오므로, 관리자 한두 명은 비밀번호로 들어올 수 있게 둡니다.

실제 로그인은 다섯 단계로 흐릅니다. 사용자가 우리 주소에 들어오면, 우리가 고객사 신원 공급자로 보냅니다. 그쪽에서 이미 로그인된 상태면 바로 통과하고, 아니면 로그인과 다중 인증을 요구합니다. 다중 인증은 두 가지 이상의 수단으로 신원을 확인하는 방식입니다. 확인이 끝나면 서명된 응답이 우리에게 돌아오고, 우리는 서명을 검증한 뒤 세션을 만듭니다.

적합한 상황과 한계

붙일 값이 있는 자리는 분명합니다. 직원 수가 많은 조직, 계정 관리를 감사받는 산업, 도구를 열 개 넘게 쓰는 회사입니다. 이런 고객에게는 기능 하나가 아니라 계약 조건입니다. 그래서 요금제에서도 기업 플랜에만 넣는 경우가 많습니다.

한계는 다섯 가지입니다.

  1. 한 곳이 멈추면 전부 멈춥니다. 신원 공급자에 장애가 나면 그 회사 사람 전원이 우리 서비스에 못 들어옵니다.
  2. 고객사마다 설정이 다릅니다. 규격은 표준이지만 실제로는 값 이름과 주소 형식이 조금씩 달라서, 고객사가 늘어날수록 지원 문의도 함께 늘어납니다.
  3. 로그아웃이 깔끔하지 않습니다. 우리 쪽 세션을 끊어도 신원 공급자 쪽이 살아 있으면 다시 들어옵니다. 전체를 끊는 절차는 규격에 있지만 구현이 제각각입니다.
  4. 개인 사용자에게는 쓸모가 없습니다. 회사 계정이 없는 사람에게는 붙일 대상이 없습니다.
  5. 인가를 해결해 주지 않습니다. 인가는 무엇을 할 수 있는지 권한을 확인하는 절차인데, 신원 공급자는 누구인지만 알려 줍니다. 권한은 역할 기반 접근 제어처럼 우리 쪽에서 따로 정해야 합니다.

실무 용례

"이 고객사는 SSO 없으면 계약이 안 됩니다. 기업 플랜 조건에 넣죠."

기능이 아니라 거래 조건이라는 뜻입니다.

"포털에서 눌러 들어오는 흐름을 안 만들었어요. 그쪽이 기본 동선입니다."

한 방향만 구현해 실제 사용자가 못 들어온다는 지적입니다.

"SSO 붙였는데 권한은 여전히 손으로 주고 있어요."

인증만 연결됐고 인가는 그대로라는 말입니다.

페이지덱은 기업 플랜에만 이 기능을 붙였습니다. 태오가 먼저 만든 것은 두 규격 중 하나뿐이었는데, 수아가 상담한 고객 다섯 곳 중 셋이 다른 규격을 쓰고 있어서 나머지도 만들게 됐습니다.

규원이 확인한 것은 계정 해지 쪽이었습니다. 로그인만 연결하면 퇴사자가 못 들어오는 것은 맞지만, 우리 쪽에 남은 계정은 여전히 유료 사용자 수에 잡히고 있었습니다. 그래서 신원 공급자에서 사람이 빠지면 우리 계정도 꺼지게 연결했습니다.

흔한 오해

소셜 로그인과 같은 것으로 읽는 경우가 가장 많습니다. 둘 다 다른 곳 계정으로 들어오는 방식이라 화면에서 보이는 모습이 비슷합니다. 하지만 계정을 누가 통제하는지가 다릅니다. 소셜 로그인은 개인이 자기 계정으로 들어오는 것이고, 싱글 사인온은 회사가 직원 계정을 통제하는 것입니다. 회사가 계정을 끄면 서비스 접근이 함께 끊기는지가 갈림길이고, 기업 고객이 요구하는 것은 뒤쪽입니다.

붙이면 보안이 강해진다고 보는 것도 흔합니다. 보안 담당자가 요구하는 기능이니 그렇게 들립니다. 하지만 이 방식 자체가 하는 일은 확인을 한 곳으로 모으는 것뿐입니다. 실제로 보안을 올리는 것은 그 한 곳에 걸린 다중 인증과 접속 조건이고, 모아 둔 곳이 약하면 위험도 함께 모입니다. 비밀번호 하나로 들어가는 신원 공급자에 붙이면 문이 열두 개에서 하나로 줄어든 것일 뿐입니다.

자주 헷갈리는 용어

용어무엇을 하는가싱글 사인온과의 차이
OAuth비밀번호를 넘기지 않고 권한만 위임합니다규격이고, 무엇을 할 수 있게 허락하는 쪽입니다. 싱글 사인온은 그 위에서 누구인지 확인하는 목적으로 쓰이는 방식입니다
소셜 로그인개인 계정으로 바로 가입하게 합니다계정 주인이 개인입니다. 회사가 끄면 접근이 끊기는 통제가 없어서 기업 고객의 요구를 채우지 못합니다

같이 보면 좋은 페이지

  • 애플리케이션 보안

    이 방식이 어느 영역의 한 부분인지 먼저 봅니다

  • 인증

    이 방식이 한 곳으로 모으는 절차를 확인합니다

마지막 업데이트 2026-09-16