Single Sign-On (SSO)

What is SSO (Single Sign-On) and Why is it Important?

Today, we navigate through a multitude of applications and services. The number of services required for work alone—such as email, cloud storage, collaboration tools, and ERP systems—is substantial. What if you had to use a different ID and password for each of these services and log in manually every time? Users would experience significant password fatigue, and companies would struggle with managing employee accounts and security.

SSO (Single Sign-On) is a powerful solution to these problems. It’s an Identity and Access Management (IAM) technology that allows you to gain access to multiple applications and services with a single Authentication event. Since users only need to remember one set of credentials, the user experience is greatly improved. For businesses, security is enhanced as they can control and monitor user access from a centralized point.

Core Benefits of SSO

• Increased User Convenience: Service accessibility is greatly improved as there’s no need to remember and repeatedly enter multiple passwords.
• Enhanced Security: Companies can establish much stronger security by applying Multi-Factor Authentication (MFA) and sophisticated access policies at a central Authentication point (IdP), rather than relying on the security of individual services. It also reduces the risk of users using the same or similar passwords across multiple services.
• Improved Operational Efficiency: IT departments can significantly reduce the burden of repetitive tasks like user account management (creation, modification, deletion) and password reset requests. When an employee leaves the company, access to all connected services can be revoked at once simply by deactivating the central account.

---

Analysis of Core SSO Technologies and Security Aspects

SSO might seem like magic, but behind it lie standardized protocols. These protocols define the rules for establishing trust and securely exchanging Authentication information between an Identity Provider (IdP), which verifies identity, and a Service Provider (SP), which the user wants to access. Representative protocols include SAML, OAuth 2.0, and OIDC.

1. SAML (Security Assertion Markup Language)

SAML is an XML-based open standard protocol designed primarily for web-based SSO in enterprise environments. SAML 2.0, released in 2005, is now a widely used industry standard.

How SAML Works (Based on SP-Initiated Flow)

1. User Request: A user attempts to access an SP (e.g., Salesforce) through a web browser.
2. SAML Request Generation: The SP determines the user is not authenticated and generates a SAML Authentication Request (AuthnRequest) to verify the user’s identity.
3. Redirection to IdP: The SP redirects the user’s browser to the IdP (e.g., Okta, ADFS), passing along the SAML request.
4. User Authentication: The IdP presents a login page to the user and requests credentials. It may also require MFA if necessary.
5. SAML Response (Assertion) Generation: Upon successful Authentication, the IdP creates an XML-formatted SAML Assertion containing the user’s identity information (email, department, etc.) and permissions, and adds a digital signature.
6. Redirection to SP and Response Delivery: The IdP redirects the user’s browser back to the SP, delivering the signed SAML Assertion.
7. Assertion Verification and Login: The SP uses the IdP’s public key to verify the digital signature of the SAML Assertion. If the signature is valid, it trusts the user information in the Assertion, creates a session, and grants the user access to the service.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_... " Version="2.0" IssueInstant="2025-07-26T18:00:00Z">
  <saml:Issuer>https://idp.example.com/idp</saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    </ds:Signature>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@example.com</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData NotOnOrAfter="2025-07-26T18:05:00Z" Recipient="https://sp.example.com/acs"/>
    </sm:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2025-07-26T17:55:00Z" NotOnOrAfter="2025-07-26T18:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com/metadata</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2025-07-26T18:00:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
</saml:Assertion>

Security Aspects of SAML

• Strengths:
  • Digital Signature: The SAML Assertion is signed with the IdP’s private key, allowing the SP to verify the Assertion’s integrity and the sender’s (IdP’s) authenticity. This prevents tampering with the Assertion through Man-in-the-Middle (MITM) attacks.
  • Replay Attack Prevention: The Assertion includes a validity period (NotOnOrAfter) and a unique ID (ID), which prevents a captured Assertion from being reused later.
  • Audience Restriction: The Audience tag specifies that the Assertion is intended only for a particular SP, preventing it from being used with other SPs.

SAML Protocol-Related Vulnerabilities

Because SAML is XML-based, it can be susceptible to attacks that exploit weaknesses in XML parsers and trust relationships.

• SAML Assertion Tampering and Replay Attacks
  • Check Item: Can a user log in by capturing and replaying a used SAML Assertion? (Replay Attack)
  • Testing Method: Intercept the SAML response using a proxy tool like Burp Suite. Try to modify time-related values like NotOnOrAfter (expiration time) or IssueInstant (issue time), or simply resend it as is. The attack may succeed if the Service Provider (SP) does not properly validate the Assertion’s ID.
• XML Signature Wrapping (XSW) Attacks
  • Check Item: If manipulated data is inserted into the XML alongside the original digitally signed data, does the SP recognize the manipulated data as valid?
  • Testing Method: Modify the structure of the SAML response XML. For example, keep the signed Subject (user information) block intact but add a new Subject block containing the attacker’s email in an unsigned area. If the SP’s XML parser handles signature verification and data parsing separately, it might validate the signature as correct while processing the attacker’s information.
• Signature Removal and Audience Modification
  • Check Item: Does the SP accept the SAML Assertion if the digital Signature element is completely removed, or if the Audience value, which defines the intended service, is changed to another service’s URL?
  • Testing Method: Use a proxy tool to delete the signature element or change the URL within the Audience tag to an arbitrary value and send it. If the SP fails to verify the presence of a signature or the Audience match, an attacker could impersonate other users or reuse an Assertion intended for another service.
• XML External Entity (XXE) Injection
  • Check Item: Does the SP’s SAML XML parser allow loading of external entities, potentially enabling an attacker to read internal server files or perform Server-Side Request Forgery (SSRF)?
  • Testing Method: Inject an XXE payload into a SAML request or response to attempt to read system files like /etc/passwd or induce an HTTP request to another server on the internal network.
• Security of the IdP Itself: The IdP is a single point of trust for all Authentication. If the IdP is compromised, all connected SPs are at risk. Therefore, robust access control, MFA enforcement, and monitoring of the IdP itself are critically important.

2. OAuth 2.0 (Open Authorization 2.0)

OAuth 2.0 is not an SSO protocol but a framework for Authorization. This means it’s not used to ‘authenticate’ users, but rather to delegate permission for a third-party application (Client) to access user data on a specific service (Resource Server). However, because user information obtained through this Authorization process can be used to handle logins, it is widely used as a foundational technology for implementing SSO. Features like “Sign in with Google” or “Sign in with Facebook” are prime examples.

How OAuth 2.0 Works (Based on Authorization Code Grant)

1. User Authorization Request: The client application sends the user to an Authorization Server, like Google. It specifies what permissions (scope, e.g., profile, email) it needs.
2. User Consent and Authentication: The Authorization Server asks the user to log in and confirm whether they consent to the permissions requested by the client application.
3. Authorization Code Issuance: Once the user consents, the Authorization Server issues a temporary Authorization Code and redirects the user’s browser back to the client application with this code.
4. Access Token Exchange: The client application sends the received Authorization Code, along with its Client ID and Client Secret, to the Authorization Server via a back-channel.
5. Access Token Issuance: The Authorization Server verifies the Authorization Code and, if valid, issues an Access Token to the client application.
6. API Call: The client application uses this Access Token to request user information from the Resource Server (e.g., Google People API).
7. Resource Delivery: The Resource Server validates the Access Token and, if valid, provides the requested user information to the client application. The client app then uses this information to log the user in.

Security Aspects of OAuth 2.0

• Strengths:
  • No Credential Exposure: Users do not expose their ID and password directly to the client application; they only provide it to the trusted Authorization Server.
  • Limited Scope of Permissions: The client application can only access data within the explicitly requested and approved scope.
  • Token-Based Access: All API requests are made via short-lived Access Tokens, so even if a token is compromised, the damage is limited.
• Security Considerations:
  • CSRF (Cross-Site Request Forgery): The state parameter must be used to prevent CSRF attacks during the Authorization request and redirection process. The client should generate an unpredictable state value, send it to the Authorization Server, and verify that the same value is returned upon redirection.
  • Authorization Code Theft: Communication between the client and the Authorization Server must be encrypted with TLS. For public clients like mobile apps, it is essential to use PKCE (Proof Key for Code Exchange) to prevent an attacker from exchanging a stolen Authorization Code for an Access Token.
  • Access Token Theft: The Access Token is a Bearer Token, meaning anyone who possesses it can access the user’s resources. Therefore, strategies such as setting short expiration times for tokens and using Refresh Tokens for sensitive operations are necessary.

3. OIDC (OpenID Connect)

OIDC is a thin identity layer built on top of the OAuth 2.0 protocol. Since OAuth 2.0 focuses solely on ‘Authorization’, it lacked a standardized method for user ‘Authentication’. OIDC was created to solve this problem.

OIDC uses the same Authorization flow as OAuth 2.0 but issues an ID Token in addition to the Access Token. The ID Token is in JWT (JSON Web Token) format and contains standardized Authentication information, such as who the user is and when and how they authenticated.

The Core of OIDC: The ID Token

The ID Token is used by the client app to verify information about the user. It includes standard claims such as:

• iss (Issuer): The IdP that issued the token.
• sub (Subject): A unique identifier for the user.
• aud (Audience): The client that is the intended recipient of the token.
• exp (Expiration Time): The token’s expiration time.
• iat (Issued At): The time the token was issued.
• nonce: A value used to prevent CSRF and replay attacks.

By verifying the ID Token’s signature and checking claims like iss, aud, and exp, the client application can securely authenticate the user and process the login.

Security Aspects of OIDC

OIDC inherits the security model of OAuth 2.0, so all the security considerations mentioned for OAuth 2.0 apply. In addition:

• Strengths:
  • Standardized Authentication Information: The ID Token allows the client to directly parse and verify the user’s identity. This is more concise and efficient than OAuth 2.0, which requires a separate API call (to the UserInfo endpoint) with an Access Token.
  • Strong Replay Attack Prevention: The nonce claim can be used to strongly bind a specific Authentication request to an ID Token. The client generates a nonce value in its Authentication request, and the IdP includes it in the returned ID Token, allowing the client to verify that the response corresponds to its original request.

OAuth 2.0 / OIDC-Related Vulnerabilities

OAuth/OIDC relies heavily on redirection and tokens, making them susceptible to attacks that exploit flaws in these processes.

• Insufficient Redirect URI Validation
  • Check Item: When the IdP redirects to the client app, does it strictly validate that the URI matches the pre-registered one, or does it allow similar patterns?
  • Testing Method: Manipulate the redirect_uri parameter in the authentication request to a URI containing an attacker’s server domain, a subdomain, or a different path. If validation is weak, the Authorization Code or token could be leaked to the attacker (Open Redirect vulnerability).
• Lack of CSRF Defense (state parameter validation)
  • Check Item: Does the client verify that the state parameter value used in the authentication request is the same one returned in the authentication response?
  • Testing Method: Remove or alter the state parameter from a normal authentication request and trick a victim into visiting the URL. If the client does not validate the state value, an attacker can link the victim’s account to their own IdP account, leading to account takeover.
• Authorization Code Interception
  • Check Item: Is PKCE (Proof Key for Code Exchange) being used correctly in public client environments (e.g., mobile apps, SPAs)?
  • Testing Method: In a mobile environment, an Authorization Code can be intercepted by a malicious app when passed via a custom scheme. If PKCE is not implemented, an attacker can use the intercepted code to obtain an Access Token and take over the user’s account.
• Insecure JWT (ID Token) Configuration
  • Check Item: Is the signature of the OIDC ID Token (JWT) properly verified? Is it vulnerable to attacks that change the algorithm to none?
  • Testing Method: Change the algorithm (alg) field in the ID Token’s header from HS256 to none and remove the signature part before sending. If the server trusts it, an attacker can impersonate a user. Additionally, verify that the token’s expiration time (exp), issuer (iss), and audience (aud) claims are correctly validated.

Common Logic and Session Management Vulnerabilities

• Flaws in Account Linking Logic
  • Check Item: If a user already has an account registered with an email/password, how is a new login attempt via SSO from a social account with the same email address handled?
  • Testing Method: Knowing the victim’s email address, an attacker attempts to log into the service via SSO using their own social account. If the service links the attacker’s social account to the existing victim’s account based only on the email address, account takeover becomes possible.
• Incomplete Logout
  • Check Item: When a user logs out from the SP, is the central session at the IdP also terminated? (Single Log-Out)
  • Testing Method: After logging out from an SP, try accessing the IdP page or another SP page directly in the browser to see if login occurs without re-authentication. If the central session remains active, it can lead to serious security issues, especially on public computers.

Conclusion: Which Technology Should You Choose?

• SAML: Shows strong performance for web-based SSO between corporate internal systems. It remains an important choice for legacy systems and enterprise application (B2B) environments.
• OAuth 2.0 + OIDC: Is the de facto standard for modern web, mobile, and Single Page Application (SPA) environments. It provides a flexible Authorization framework with a standardized identity layer on top, making it easy to develop and apply to various scenarios. If you are implementing SSO in a new application, OIDC should be your primary consideration.

SSO is not just a tool for convenience. When understood and implemented correctly, it is a key security strategy that allows for effective, centralized control over security in a distributed environment. It is crucial to clearly understand the operating principles and security trade-offs of each protocol to select the most appropriate technology for your service environment and to thoroughly prepare against potential threats.

---

SSO(Single Sign-On)란 무엇이며 왜 중요한가?

오늘날 우리는 수많은 애플리케이션과 서비스를 넘나들며 살아갑니다. 이메일, 클라우드 스토리지, 협업 툴, ERP 시스템 등 업무에 필요한 서비스만 해도 그 수가 상당하죠. 만약 이 모든 서비스에 각각 다른 아이디와 비밀번호를 사용하고 일일이 로그인해야 한다면 어떨까요? 사용자는 비밀번호 관리에 큰 피로감을 느낄 것이고, 기업은 직원들의 계정 관리 및 보안에 어려움을 겪게 될 것입니다.

SSO(Single Sign-On)는 이러한 문제를 해결하기 위한 강력한 솔루션입니다. SSO는 한 번의 Authentication으로 여러 애플리케이션 및 서비스에 대한 접근 권한을 얻는 ID 및 접근 관리(IAM) 기술입니다. 사용자는 단 하나의 자격 증명(Credential)만 기억하면 되므로 사용자 경험이 크게 향상되고, 기업은 중앙화된 지점에서 사용자의 접근을 통제하고 모니터링할 수 있어 보안이 강화됩니다.

SSO의 핵심 이점

• 사용자 편의성 증대: 여러 개의 비밀번호를 기억하고 반복적으로 입력할 필요가 없어 서비스 접근성이 크게 향상됩니다.
• 보안 강화: 기업은 중앙 Authentication 지점(IdP)에서 다단계 Authentication(MFA), 정교한 접근 정책 등을 적용하여 개별 서비스에 의존하는 것보다 훨씬 강력한 보안을 구축할 수 있습니다. 또한, 사용자가 여러 서비스에 동일하거나 유사한 비밀번호를 사용하는 위험을 줄여줍니다.
• 운영 효율성 향상: IT 부서는 사용자 계정 관리(생성, 수정, 삭제) 및 비밀번호 재설정 요청 처리와 같은 반복적인 업무 부담을 크게 줄일 수 있습니다. 사용자가 퇴사할 경우, 중앙 계정만 비활성화하면 연결된 모든 서비스의 접근을 한 번에 차단할 수 있습니다.

---

SSO 핵심 기술 분석 및 보안적 측면

SSO는 마법처럼 보일 수 있지만, 그 이면에는 표준화된 프로토콜들이 존재합니다. 이 프로토콜들은 신원을 확인해 주는 ID 공급자(IdP, Identity Provider)와 사용자가 접근하려는 서비스 제공자(SP, Service Provider) 간의 신뢰를 구축하고 Authentication 정보를 안전하게 교환하는 규칙을 정의합니다. 대표적인 프로토콜로는 SAML, OAuth 2.0, OIDC가 있습니다.

1. SAML (Security Assertion Markup Language)

SAML은 주로 엔터프라이즈 환경의 웹 기반 SSO를 위해 설계된 XML 기반의 개방형 표준 프로토콜입니다. 2005년에 발표된 SAML 2.0이 현재 업계 표준으로 널리 사용되고 있습니다.

SAML 작동 방식 (SP-Initiated Flow 기준)

1. 사용자 요청: 사용자가 웹 브라우저를 통해 SP(예: Salesforce)에 접근을 시도합니다.
2. SAML 요청 생성: SP는 사용자가 Authentication되지 않았음을 확인하고, 사용자의 신원을 확인해달라는 SAML Authentication 요청(AuthnRequest)을 생성합니다.
3. IdP로 리디렉션: SP는 사용자의 브라우저를 IdP(예: Okta, ADFS)로 리디렉션시키면서 SAML 요청을 함께 전달합니다.
4. User Authentication: IdP는 사용자에게 로그인 페이지를 보여주고 자격 증명을 요구합니다. 필요시 MFA를 추가로 요청할 수 있습니다.
5. SAML 응답(Assertion) 생성: Authentication이 성공하면, IdP는 사용자의 신원 정보(이메일, 부서 등)와 권한을 담은 XML 형식의 SAML Assertion을 생성하고 디지털 서명을 추가합니다.
6. SP로 리디렉션 및 응답 전달: IdP는 사용자의 브라우저를 다시 SP로 리디렉션시키면서 서명된 SAML Assertion을 전달합니다.
7. Assertion 검증 및 로그인: SP는 IdP의 공개키를 사용하여 SAML Assertion의 디지털 서명을 검증합니다. 서명이 유효하면 Assertion에 담긴 사용자 정보를 신뢰하고 세션을 생성하여 사용자에게 서비스 접근을 허용합니다.

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_... " Version="2.0" IssueInstant="2025-07-26T18:00:00Z">
  <saml:Issuer>https://idp.example.com/idp</saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    </ds:Signature>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@example.com</saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData NotOnOrAfter="2025-07-26T18:05:00Z" Recipient="https://sp.example.com/acs"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2025-07-26T17:55:00Z" NotOnOrAfter="2025-07-26T18:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com/metadata</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2025-07-26T18:00:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
</saml:Assertion>

SAML의 보안적 측면

• 강점:
  • 디지털 서명: SAML Assertion은 IdP의 개인키로 서명되어 SP가 Assertion의 무결성과 발신자(IdP)의 신뢰성을 검증할 수 있습니다. 이를 통해 중간자 공격(MITM)에 의한 Assertion 변조를 방지합니다.
  • 재전송 공격 방지: Assertion에는 유효 기간(NotOnOrAfter)과 고유 ID(ID)가 포함되어 있어, 탈취된 Assertion이 나중에 재사용되는 것을 막습니다.
  • 대상 지정: Audience 태그를 통해 Assertion이 특정 SP만을 위한 것임을 명시하여 다른 SP에서 사용될 수 없도록 합니다.

SAML 프로토콜 관련 취약점

SAML은 XML 기반으로 작동하기 때문에 XML 파서와 신뢰 관계 설정의 허점을 노리는 공격에 취약할 수 있습니다.

• SAML Assertion 변조 및 재전송 공격
  • 점검 항목: 한 번 사용된 SAML Assertion을 탈취하여 그대로 재전송했을 때 로그인이 되는가? (Replay Attack)
  • 테스트 방법: Burp Suite과 같은 프록시 툴로 SAML 응답을 가로챈 뒤, NotOnOrAfter (만료 시간)나 IssueInstant (발급 시간) 같은 시간 관련 값을 수정하거나 그대로 다시 보내봅니다. SP(서비스 제공자)가 Assertion의 ID를 제대로 검증하지 않으면 공격이 성공할 수 있습니다.
• XML 서명 래핑 (XML Signature Wrapping, XSW) 공격
  • 점검 항목: 디지털 서명이 된 원본 데이터 외에 조작된 데이터를 XML에 함께 삽입했을 때, SP가 조작된 데이터를 유효한 것으로 인식하는가?
  • 테스트 방법: SAML 응답의 XML 구조를 변경합니다. 예를 들어, 서명된 Subject(사용자 정보) 블록은 그대로 두고, 공격자의 이메일이 담긴 새로운 Subject 블록을 서명되지 않은 영역에 추가합니다. SP의 XML 파서가 서명 검증과 데이터 파싱을 분리해서 처리하면, 서명은 유효하다고 판단하면서 실제 데이터는 공격자의 정보로 인식할 수 있습니다.
• 서명 제거 및 대상(Audience) 변경
  • 점검 항목: SAML Assertion에서 디지털 서명(Signature) 부분을 완전히 제거하거나, Assertion이 유효한 서비스 대상을 정의하는 Audience 값을 다른 서비스의 URL로 변경했을 때 SP가 이를 수용하는가?
  • 테스트 방법: 프록시 툴로 서명 부분을 삭제하거나, Audience 태그 안의 URL을 임의의 값으로 변경하여 전송합니다. SP가 서명 존재 여부나 Audience 일치 여부를 검증하지 않으면, 다른 사용자로 위장하거나 다른 서비스용 Assertion을 재사용할 수 있습니다.
• XML 외부 개체 (XML External Entity, XXE) 주입
  • 점검 항목: SP의 SAML XML 파서가 외부 개체 로드를 허용하여, 서버의 내부 파일을 읽거나 서버 측 요청 변조(SSRF)를 유발할 수 있는가?
  • 테스트 방법: SAML 요청 또는 응답에 XXE 페이로드를 삽입하여 /etc/passwd 같은 시스템 파일을 읽도록 시도하거나, 내부 네트워크의 다른 서버로 HTTP 요청을 보내도록 유도합니다.
• IdP 자체의 보안: IdP는 모든 Authentication의 중심점(Single Point of Trust)이므로, IdP가 침해당하면 연결된 모든 SP가 위험에 처하게 됩니다. 따라서 IdP 자체의 접근 제어, MFA 적용, 모니터링이 매우 중요합니다.

2. OAuth 2.0 (Open Authorization 2.0)

OAuth 2.0은 SSO 프로토콜이 아니라 Authorization를 위한 프레임워크입니다. 즉, 사용자를 ‘Authentication’하는 것이 아니라, 특정 서비스(Resource Server)에 있는 사용자 데이터에 제3의 애플리케이션(Client)이 접근할 수 있도록 권한을 위임하는 데 사용됩니다. 하지만 이 Authorization 과정을 통해 사용자 정보를 얻어와 로그인을 처리할 수 있기 때문에, SSO 구현의 기반 기술로 널리 활용됩니다. “Google로 로그인하기”, “Facebook으로 로그인하기” 기능이 대표적인 예입니다.

OAuth 2.0 작동 방식 (Authorization Code Grant 기준)

1. 사용자 Authorization 요청: 클라이언트 앱이 사용자를 Google과 같은 Authorization Server로 보냅니다. 이때 어떤 권한(scope, 예: profile, email)이 필요한지 명시합니다.
2. 사용자 동의 및 Authentication: Authorization 서버는 사용자에게 로그인을 요구하고, 클라이언트 앱이 요청한 권한에 대해 동의하는지 확인합니다.
3. Authorization Code 발급: 사용자가 동의하면, Authorization 서버는 임시 Authorization Code를 발급하여 사용자의 브라우저를 통해 클라이언트 앱으로 리디렉션시킵니다.
4. Access Token 교환: 클라이언트 앱은 백엔드 채널을 통해 전달받은 Authorization Code를 클라이언트 ID, 클라이언트 시크릿과 함께 Authorization 서버에 보냅니다.
5. Access Token 발급: Authorization 서버는 Authorization Code를 검증하고 유효하다면 Access Token을 클라이언트 앱에 발급합니다.
6. API 호출: 클라이언트 앱은 이 Access Token을 사용하여 리소스 서버(예: Google People API)에 사용자 정보를 요청합니다.
7. 리소스 제공: 리소스 서버는 Access Token을 검증하고, 유효하면 요청된 사용자 정보를 클라이언트 앱에 제공합니다. 클라이언트 앱은 이 정보를 바탕으로 사용자를 로그인시킵니다.

OAuth 2.0의 보안적 측면

• 강점:
  • 자격 증명 비노출: 사용자는 자신의 ID와 비밀번호를 클라이언트 앱에 직접 노출하지 않고, 신뢰하는 Authorization 서버에만 제공합니다.
  • 권한 범위 제한: 클라이언트 앱은 명시적으로 요청하고 동의받은 범위(scope) 내의 데이터에만 접근할 수 있습니다.
  • 토큰 기반 접근: 모든 API 요청은 수명이 짧은 Access Token을 통해 이루어지므로, 토큰이 탈취되더라도 피해를 제한할 수 있습니다.
• 보안 고려사항:
  • CSRF (Cross-Site Request Forgery): Authorization 요청 및 리디렉션 과정에서 state 파라미터를 사용하여 CSRF 공격을 방지해야 합니다. 클라이언트가 생성한 예측 불가능한 state 값을 Authorization 서버로 보냈다가 리디렉션 시 동일한 값이 돌아오는지 확인해야 합니다.
  • Authorization Code 탈취: 클라이언트와 Authorization 서버 간의 통신은 반드시 TLS로 암호화되어야 합니다. 모바일 앱과 같은 Public Client의 경우, PKCE(Proof Key for Code Exchange)를 사용하여 Authorization Code가 탈취되더라도 공격자가 Access Token을 발급받지 못하도록 방어하는 것이 필수적입니다.
  • Access Token 탈취: Access Token은 전달자 토큰(Bearer Token)이므로, 누구든 이 토큰을 획득하면 사용자의 리소스에 접근할 수 있습니다. 따라서 토큰의 유효 기간을 짧게 설정하고, 민감한 작업에는 리프레시 토큰(Refresh Token)을 사용하는 등의 전략이 필요합니다.

3. OIDC (OpenID Connect)

OIDC는 OAuth 2.0 프로토콜 위에 구축된 얇은 ID 계층(Identity Layer)입니다. OAuth 2.0이 ‘Authorization’에만 초점을 맞추다 보니, 사용자 ‘Authentication’을 위한 표준화된 방법이 부족했습니다. OIDC는 이 문제를 해결하기 위해 등장했습니다.

OIDC는 OAuth 2.0의 Authorization 흐름을 그대로 사용하면서, Access Token과 함께 ID 토큰(ID Token)이라는 것을 추가로 발급합니다. ID 토큰은 JWT(JSON Web Token) 형식이며, 사용자가 누구인지, 언제 어떻게 Authentication했는지 등 표준화된 Authentication 정보를 담고 있습니다.

OIDC의 핵심: ID 토큰

ID 토큰은 클라이언트 앱이 사용자에 대한 정보를 확인하는 데 사용됩니다. 여기에는 다음과 같은 표준 클레임(Claim)이 포함됩니다.

• iss (Issuer): 토큰을 발급한 IdP
• sub (Subject): 사용자의 고유 식별자
• aud (Audience): 토큰을 수신할 클라이언트
• exp (Expiration Time): 토큰 만료 시간
• iat (Issued At): 토큰 발급 시간
• nonce: CSRF 및 재전송 공격을 방지하기 위한 값

클라이언트 앱은 ID 토큰의 서명을 검증하고, iss, aud, exp 등의 값을 확인함으로써 안전하게 사용자를 Authentication하고 로그인 처리할 수 있습니다.

OIDC의 보안적 측면

OIDC는 OAuth 2.0의 보안 모델을 그대로 계승하므로, OAuth 2.0에서 언급된 보안 고려사항이 모두 적용됩니다. 여기에 더해,

• 강점:
  • 표준화된 Authentication 정보: ID 토큰을 통해 클라이언트는 사용자의 신원을 직접 파싱하고 검증할 수 있습니다. OAuth 2.0처럼 Access Token으로 별도의 API(UserInfo 엔드포인트)를 호출할 필요가 없어 더 간결하고 효율적입니다.
  • 강력한 재전송 공격 방지: nonce 클레임을 사용하여 특정 Authentication 요청과 ID 토큰을 강력하게 바인딩할 수 있습니다. 클라이언트가 Authentication 요청 시 생성한 nonce 값을 IdP가 발급하는 ID 토큰에 포함시켜 돌려주면, 클라이언트는 자신이 보낸 요청에 대한 응답인지 확인할 수 있습니다.

OAuth 2.0 / OIDC 관련 취약점

OAuth/OIDC는 리디렉션과 토큰에 크게 의존하므로, 이 과정의 허점을 파고드는 공격이 많습니다.

• 리디렉션 URI (Redirect URI) 검증 미흡
  • 점검 항목: IdP(ID 공급자)가 클라이언트 앱을 리디렉션 시킬 때, 사전에 등록된 URI와 정확히 일치하는지 검증하는가, 아니면 유사한 패턴의 다른 URI도 허용하는가?
  • 테스트 방법: 인증 요청 시 redirect_uri 파라미터를 조작하여 공격자의 서버 도메인이 포함된 URI나 하위 도메인, 다른 경로 등으로 변경해 봅니다. 검증이 허술하면 Authorization Code나 토큰이 공격자에게 유출될 수 있습니다. (Open Redirect 취약점)
• CSRF 방어 부재 (state 파라미터 검증 미흡)
  • 점검 항목: 인증 요청 시 사용했던 state 파라미터 값이 인증 응답 시 동일하게 돌아오는지 클라이언트가 검증하는가?
  • 테스트 방법: 정상적인 인증 요청에서 state 파라미터 값을 제거하거나 다른 값으로 변경한 후, 해당 URL로 희생자가 접근하도록 유도합니다. 클라이언트가 state 값을 검증하지 않으면, 공격자는 희생자의 계정을 자신의 IdP 계정에 연결시켜 계정을 탈취할 수 있습니다.
• 인증 코드 가로채기 (Authorization Code Interception)
  • 점검 항목: Public 클라이언트(예: 모바일 앱, SPA) 환경에서 PKCE(Proof Key for Code Exchange)를 올바르게 사용하고 있는가?
  • 테스트 방법: 모바일 환경에서 커스텀 스킴(Custom Scheme)을 통해 Authorization Code가 전달될 때, 악성 앱이 이 코드를 가로챌 수 있습니다. PKCE가 적용되지 않았다면, 공격자는 가로챈 Authorization Code로 Access Token을 발급받아 사용자 계정을 탈취할 수 있습니다.
• JWT(ID Token) 보안 설정 미흡
  • 점검 항목: OIDC의 ID 토큰(JWT) 서명을 제대로 검증하는가? 서명 알고리즘을 none으로 변경하는 공격에 취약하지 않은가?
  • 테스트 방법: ID 토큰의 헤더에 있는 알고리즘(alg) 필드를 HS256에서 none으로 변경하고 서명 부분을 제거한 뒤 전송합니다. 서버가 이를 그대로 신뢰하면 사용자를 위장할 수 있습니다. 또한, 토큰의 만료 시간(exp), 발급자(iss), 대상(aud) 클레임이 올바르게 검증되는지도 확인해야 합니다.

공통 로직 및 세션 관리 취약점

• 계정 연결 로직 허점
  • 점검 항목: 기존에 이메일/패스워드로 가입된 계정이 있는 상태에서, 동일한 이메일 주소의 소셜 로그인(SSO)으로 신규 로그인을 시도할 때 계정이 어떻게 처리되는가?
  • 테스트 방법: 희생자의 이메일 주소를 아는 상태에서, 공격자가 자신의 소셜 계정으로 해당 서비스에 SSO 로그인을 시도합니다. 만약 서비스가 이메일 주소만 보고 기존 희생자 계정에 공격자의 소셜 계정을 연결시켜 준다면, 계정 탈취가 가능해집니다.
• 불완전한 로그아웃
  • 점검 항목: SP에서 로그아웃했을 때, IdP의 중앙 세션도 함께 로그아웃되는가? (Single Log-Out)
  • 테스트 방법: SP에서 로그아웃한 후, 브라우저에서 바로 IdP 페이지나 다른 SP 페이지로 접근했을 때 재-Authentication 없이 바로 로그인이 되는지 확인합니다. 중앙 세션이 살아있다면, 공용 PC 등에서 심각한 보안 문제로 이어질 수 있습니다.

결론: 어떤 기술을 선택해야 할까?

• SAML: 주로 기업 내부 시스템 간의 웹 기반 SSO 연동에 강력한 성능을 보입니다. 레거시 시스템이나 엔터프라이즈 애플리케이션(B2B) 환경에서 여전히 중요한 선택지입니다.
• OAuth 2.0 + OIDC: 현대적인 웹, 모바일, SPA(Single Page Application) 환경에서 사실상의 표준입니다. 유연한 Authorization 프레임워크 위에 표준화된 ID 계층을 제공하여 개발이 용이하고 다양한 시나리오에 적용할 수 있습니다. 새로운 애플리케이션에 SSO를 구현한다면 OIDC가 가장 우선적으로 고려되어야 합니다.

SSO는 단순히 편의성을 위한 도구가 아닙니다. 올바르게 이해하고 구현했을 때, 분산된 환경의 보안을 중앙에서 효과적으로 통제할 수 있게 해주는 핵심적인 보안 전략입니다. 각 프로토콜의 작동 원리와 보안적 장단점을 명확히 파악하여 자신의 서비스 환경에 가장 적합한 기술을 선택하고, 잠재적 위협에 철저히 대비하는 것이 중요합니다.