SSO는 어떻게 한 번 로그인으로 여러 앱을 여나 — SAML과 OIDC 흐름 정리

결론부터. SSO는 “비밀번호를 여러 앱이 공유하는 것”이 아니다. 로그인은 신원 제공자(IdP) 한 곳에서만 하고, 각 앱은 IdP가 서명해 준 “이 사람 맞음” 증명서만 검증한다. 두 번째 앱부터 로그인 창이 안 뜨는 건 IdP가 이미 나를 알고 있어서다.

에이전트를 만들다 보면 Copilot Studio 인증 설정이든 Graph 호출이든 결국 이 구조 위에서 막힌다. 그래서 한 번 제대로 정리해 두기로 했다.

이 글은 ByteByteGo의 영상 「What Is Single Sign-on (SSO)? How It Works」를 정리·재구성하고, Microsoft Learn 문서로 Entra ID 관련 내용을 보충한 것이다.

등장인물은 셋

• 사용자(브라우저): 앱에 들어가려는 사람
• 서비스 제공자(SP): Gmail, Workday, Slack 같은 앱
• 신원 제공자(IdP): 로그인을 대신 처리하는 곳. 영상은 Okta, Auth0, OneLogin을 예로 들고, 내가 매일 쓰는 건 Microsoft Entra ID다

이 구조의 바탕 개념이 연합 신원(federated identity) 이다. 서로 독립적이지만 신뢰 관계를 맺은 시스템끼리 신원 정보를 주고받는 방식이다.

SAML 로그인 흐름 — 첫 번째 앱

비밀번호는 IdP에만 간다. 앱(SP)은 IdP가 서명한 증명서만 검증한다.

순서대로 보면 이렇다.

1. 회사 직원이 Gmail에 접속한다. 이 예에서 Gmail이 서비스 제공자(SP) 다.
2. Gmail 서버가 회사 도메인 사용자임을 알아채고, 브라우저에 SAML 인증 요청을 돌려준다.
3. 브라우저가 요청에 적힌 회사 IdP로 이동한다. 로그인 화면은 IdP가 띄운다.
4. 인증이 끝나면 IdP가 SAML 어설션을 만들어 브라우저에 준다. 사용자 정보와 “이 앱에서 무엇을 할 수 있는지”를 담은 XML 문서이고, 암호학적으로 서명돼 있다.
5. 브라우저가 이 어설션을 Gmail에 전달한다.
6. Gmail은 어설션이 정말 그 IdP가 서명한 것인지 공개키 암호로 검증하고, 어설션에 적힌 권한만큼 열어 준다.

두 번째 앱(Workday)에서는 왜 로그인이 안 뜰까

"한 번 로그인"의 정체는 앱이 나를 기억하는 게 아니라 IdP가 나를 기억하는 것이다.

Workday도 Gmail과 똑같이 회사 도메인을 감지해 SAML 요청을 보내고, 브라우저는 다시 IdP로 간다. 차이는 하나다. IdP에 이미 로그인한 상태라 로그인 단계를 건너뛰고, Workday용 권한을 담은 새 어설션만 발급한다. 나머지 검증 과정은 같다.

여기서 내가 처음에 헷갈렸던 점은, 어설션이 “통행증 한 장”이 아니라 앱마다 따로 발급된다는 것이다. 그래서 앱별로 줄 수 있는 권한을 다르게 관리할 수 있다.

SAML vs OIDC — 포장만 다르다

보안 수준의 차이가 아니라, 어떤 앱에 붙이기 쉬우냐의 차이다.

• SAML: XML 기반 개방형 표준. 회사 업무 환경에서 주로 본다.
• OIDC: 개인 구글 계정으로 YouTube에 로그인할 때 쓰는 그 방식. 서명된 XML 대신 JWT(JSON Web Token) 를 주고받는다.

영상의 결론은 둘 다 안전하다는 것이다. 신원 관리를 Okta 같은 상용 플랫폼에 맡긴 기업이라면 대부분 둘 다 지원하니, 붙이려는 앱이 어느 쪽을 쉽게 지원하느냐로 고르면 된다. 새 웹 앱을 만든다면 Google, Facebook, GitHub 같은 OIDC 제공자에 붙이는 게 무난하다고 한다.

Entra ID로 보면 — 에이전트를 만든다면 OIDC 쪽이다

영상에는 없는 부분인데, 내 환경(Microsoft Entra ID)에 대입해 Microsoft Learn 문서를 찾아봤다.

• Entra ID는 SAML이든 OIDC든 사용자 인증 → 조건부 액세스 같은 정책 검사 → 담을 신원 정보 결정까지 같은 단계를 거친다. 갈라지는 건 그 뒤 포장 방식뿐이다. SAML 앱은 XML 어설션을, OIDC 앱은 JWT를 받는다.
• 실무에서 중요한 차이가 하나 있다. SAML 토큰으로는 Microsoft Graph를 호출할 수 없다. Graph는 OIDC/OAuth로 받은 JWT가 필요하다. 그래서 로그인은 SAML로 하는 솔루션이라도 Graph를 쓰려면 OIDC 연동을 따로 붙여야 한다고 문서에 나와 있다.

메일·일정·SharePoint를 읽는 에이전트처럼 Graph를 써야 하는 앱이라면 처음부터 OIDC로 설계하는 게 맞다. 로그인만 SAML로 붙였다가 나중에 Graph 연동에서 다시 공사하는 경우가 생긴다.

정리하며

예전에는 SSO를 “회사 계정 하나로 다 들어가는 편한 기능” 정도로만 알았다. 흐름을 따라가 보니 핵심은 편의가 아니라 신뢰의 위치였다. 비밀번호는 IdP 한 곳에만 있고, 앱들은 서명만 믿는다. 그래서 IdP 한 곳에 MFA와 조건부 액세스를 걸면 모든 앱이 같이 안전해진다.

다음에 Copilot Studio 에이전트에 사용자 인증을 붙일 때는 “이 에이전트가 Graph를 부르는가?”부터 묻고 프로토콜을 고를 생각이다.

참고

• ByteByteGo, 「What Is Single Sign-on (SSO)? How It Works」 (2022-11-17) — https://www.youtube.com/watch?v=O1cRJWYF-g4
• Microsoft Learn, 「Understand Microsoft’s SSO model」 — https://learn.microsoft.com/entra/identity/enterprise-apps/understand-microsoft-sso-model
• Microsoft Learn, 「SAML versus OpenID Connect: Choose the right SSO protocol」 — https://learn.microsoft.com/entra/identity/enterprise-apps/saml-vs-oidc-decision-guide
• Microsoft Learn, 「Secure hybrid access with Microsoft Entra integration」 (SAML 토큰과 Graph) — https://learn.microsoft.com/entra/identity/enterprise-apps/secure-hybrid-access-integrations