single-sign-on-(sso)
Single Sign-On (SSO)은 사용자가 단일 로그인 자격 증명 세트로 여러 애플리케이션에 액세스할 수 있도록 하는 인증 프로세스입니다.
SSO는 다양한 시스템 및 애플리케이션에 대한 액세스를 위해 단일 ID 확인을 활성화하여 사용자 인증을 간소화합니다. 각 서비스에 대해 별도의 로그인이 필요한 대신, 사용자는 한 번 인증을 거치면 모든 권한 있는 리소스에 대한 액세스 권한을 얻습니다. 이는 일반적으로 사용자의 자격 증명을 확인하고 다른 애플리케이션이 신뢰하는 토큰 또는 어설션을 발행하는 신뢰할 수 있는 ID 제공자를 통해 수행됩니다. 이를 통해 사용자 경험이 향상되고 사용자가 관리해야 하는 암호 수를 줄이고 공격 표면을 최소화하여 보안이 강화됩니다.
graph LR
Center["single-sign-on-(sso)"]:::main
Pre_cryptography["cryptography"]:::pre --> Center
click Pre_cryptography "/terms/cryptography"
Rel_authentication["authentication"]:::related -.-> Center
click Rel_authentication "/terms/authentication"
Rel_authorization["authorization"]:::related -.-> Center
click Rel_authorization "/terms/authorization"
Rel_saas_software_as_a_service["saas-software-as-a-service"]:::related -.-> Center
click Rel_saas_software_as_a_service "/terms/saas-software-as-a-service"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 지식 테스트
🧒 5살도 이해할 수 있게 설명
It's like having a master key that unlocks all the different doors in your house, so you only need to use one key instead of a separate one for each room.
🤓 Expert Deep Dive
SSO implementations typically rely on federated identity management protocols. SAML 2.0, a widely adopted standard, uses XML-based assertions exchanged between an IdP and SPs, often facilitated by browser redirects (HTTP POST binding). OAuth 2.0, primarily an authorization framework, is frequently used in conjunction with OpenID Connect (OIDC) for authentication. OIDC builds upon OAuth 2.0, adding an identity layer that provides user profile information and a standardized ID token. Key architectural components include the Identity Provider (authenticates users and issues tokens), Service Providers (rely on IdP for authentication), and the user's client (facilitates token exchange). Security considerations involve robust token validation (signature verification, expiration checks, audience restriction), secure transport (TLS/SSL), and protection against token replay attacks. The trade-off is the increased criticality of the IdP; a compromise of the IdP can lead to widespread access breaches across all connected SPs.