Security+ Academy · 강의

연합형 ID: SAML, OAuth, OpenID Connect

SSO, SAML 어설션, OAuth 2.0 흐름, OpenID Connect 토큰이 사용자의 한 번의 인증으로 여러 애플리케이션에 안전하게 접근하도록 지원하는 방식을 학습합니다.

레슨 4/413개 단계

연합형 ID: SAML, OAuth, OpenID Connect은(는) CoddyKit의 무료 Security+ Academy 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Security+ Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Security+ Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

도메인 간 ID의 문제

현대적인 기업 환경에서 직원은 클라우드 앱, SaaS 도구, 파트너 포털, 내부 시스템 등 수십 개의 애플리케이션에 접근해야 하며, 각 애플리케이션은 서로 다른 조직에서 관리할 수 있습니다. 각각 별도의 계정을 만들고 관리하는 방식은 안전하지 않고(자격 증명 확산) 비효율적입니다. 페더레이션 ID는 ID 공급자(IdP)라는 신뢰할 수 있고 권위 있는 ID 출처가 사용자를 인증하고, 조직 경계를 넘어 인증된 ID를 서비스 제공자(SP)와 공유하도록 하여 이 문제를 해결합니다. 사용자는 한 번 인증하면 자격 증명을 다시 입력하지 않고 여러 시스템에 접근할 수 있습니다.

싱글 사인온(SSO) 기초

싱글 사인온(SSO)을 사용하면 사용자가 한 번 인증한 후 세션이 유지되는 동안 다시 인증하지 않고 여러 애플리케이션에 접근할 수 있습니다. 사용자는 ID 공급자(기업 Active Directory, Okta, Azure AD)에 로그인하고 세션 토큰 또는 Assertion을 받은 다음, 방문하는 각 서비스 제공자에게 이 토큰을 제시합니다. SSO는 사용자가 관리해야 하는 비밀번호 수를 줄여(재사용 감소) 보안을 향상하고, 중앙에서 인증 정책을 적용할 수 있게 하며, IdP 수준에서 계정이 비활성화될 때 통합된 모든 애플리케이션의 접근을 즉시 철회할 수 있게 합니다.

SAML 2.0: XML 기반 페더레이션

SAML(보안 Assertion 마크업 언어) 2.0은 ID 공급자와 서비스 제공자 간에 인증 및 Authorization 데이터를 교환하기 위한 XML 기반 개방형 표준입니다. SAML 흐름은 다음과 같습니다. (1) 사용자가 서비스 제공자(예: Salesforce)에 접근합니다. (2) SP가 ID 공급자(예: Okta)로 리디렉션합니다. (3) 사용자가 IdP에서 인증합니다. (4) IdP가 사용자의 ID와 Attribute를 포함하는 서명된 XML SAML Assertion을 발급합니다. (5) Assertion이 SP로 반환됩니다. (6) SP가 IdP의 공개 키를 사용하여 Assertion의 서명을 검증하고 접근 권한을 부여합니다. SAML은 웹 애플리케이션의 기업용 SSO에 널리 사용됩니다.

<!-- Simplified SAML Assertion structure -->
<saml:Assertion xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion'
  IssueInstant='2026-06-21T10:00:00Z'
  ID='_abc123'>
  <saml:Issuer>https://idp.company.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID>alice@company.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore='2026-06-21T10:00:00Z'
                   NotOnOrAfter='2026-06-21T10:05:00Z'/>
  <saml:AttributeStatement>
    <saml:Attribute Name='groups'>
      <saml:AttributeValue>Sales</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
  <!-- Signature verifies IdP signed this assertion -->
</saml:Assertion>

SAML 역할: IdP, SP 및 주체

SAML 페더레이션에는 세 당사자가 참여합니다. 주체는 접근을 요청하는 사용자 또는 시스템이며, 인증 프로세스를 시작합니다. ID 공급자(IdP)는 주체를 인증하고 Assertion을 발급하는 권위 있는 ID 출처입니다. Microsoft Azure AD, Okta, Ping Identity, ADFS 등이 그 예입니다. 서비스 제공자(SP)는 Assertion을 받아 이를 기반으로 접근 권한을 부여합니다. Salesforce, Google Workspace, AWS 및 SAML을 지원하는 모든 애플리케이션이 그 예입니다. SP와 IdP는 서로의 엔드포인트 URL과 서명 인증서를 포함하는 메타데이터를 교환하여 사전에 신뢰 관계를 수립합니다.

OAuth 2.0: Authorization 프레임워크

OAuth 2.0은 인증 프로토콜이 아니라 Authorization 프레임워크입니다. 사용자의 자격 증명을 노출하지 않고 타사 애플리케이션이 사용자를 대신하여 리소스에 접근할 수 있게 합니다. 대표적인 사용 사례는 ‘이 사진 편집 앱이 Google Photos에 접근하도록 허용하시겠습니까?’입니다. OAuth 2.0은 네 가지 역할을 도입합니다. 리소스 소유자(사용자), Client(타사 앱), Authorization 서버(토큰 발급), 리소스 서버(보호된 리소스 호스팅)입니다. 사용자가 Client를 Authorization하면 Client는 접근 토큰을 받아 리소스 서버에 제시하며, 사용자의 실제 비밀번호는 전혀 필요하지 않습니다.

OAuth 2.0 Authorization 코드 흐름

Authorization 코드 흐름은 웹 애플리케이션에 가장 안전한 OAuth 2.0 흐름입니다. 흐름은 다음과 같습니다. (1) Client가 요청된 scope와 함께 사용자를 Authorization 서버로 리디렉션합니다. (2) 사용자가 Authorization 서버에서 인증하고 동의를 부여합니다. (3) Authorization 서버가 수명이 짧은 Authorization 코드와 함께 사용자를 다시 리디렉션합니다. (4) Client가 Client 자격 증명을 사용한 서버 간 호출을 통해 코드를 접근 토큰(선택적으로 갱신 토큰)으로 교환합니다. (5) Client가 접근 토큰을 사용하여 리소스 서버를 호출합니다. 코드 교환은 서버 측에서 수행되므로 접근 토큰이 브라우저 기록이나 로그에 노출되는 것을 방지합니다.

# OAuth 2.0 Authorization Code Flow (step 3-4)
# Step 3: User is redirected back to client with auth code
# GET https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

# Step 4: Client exchanges code for access token (server-to-server)
curl -X POST https://auth.example.com/oauth2/token \
  -d 'grant_type=authorization_code' \
  -d 'code=SplxlOBeZQQYbYS6WxSbIA' \
  -d 'redirect_uri=https://app.example.com/callback' \
  -d 'client_id=client_abc' \
  -d 'client_secret=secret_xyz'
# Response: {'access_token': 'MTQ0Nj...', 'token_type': 'Bearer', 'expires_in': 3600}

OpenID 연결: OAuth에 인증 추가

OpenID 연결(OIDC)은 OAuth 2.0 위에 구축된 인증 계층입니다. OAuth는 Client가 수행할 수 있는 작업을 증명하는 접근 토큰을 통해 Authorization만 제공하지만, OIDC는 사용자가 누구인지 증명하는 ID 토큰을 통해 인증을 추가합니다. OIDC는 OAuth 흐름에 openid scope를 추가하고, 접근 토큰과 함께 서명된 JWT(JSON 웹 토큰) ID 토큰을 반환합니다. ID 토큰에는 사용자를 식별하는 클레임(이름, 이메일, sub[주체 식별자])이 포함됩니다. OIDC는 이제 소비자 대상 SSO의 주요 프로토콜이며, ‘Google/Apple/Microsoft로 로그인’ 버튼은 모두 OIDC를 사용합니다.

# OIDC ID Token is a JWT with three base64url-encoded parts:
# header.payload.signature

# Decoded payload example:
# {
#   'iss': 'https://accounts.google.com',
#   'sub': '110169484474386276334',
#   'aud': 'client_id_abc123',
#   'exp': 1750000000,
#   'iat': 1749996400,
#   'email': 'alice@gmail.com',
#   'name': 'Alice Smith',
#   'email_verified': true
# }

# The signature is verified with the IdP's public key (from JWKS endpoint)

JWT: 현대 인증의 토큰

JSON 웹 토큰(JWT)은 당사자 간에 클레임을 표현하기 위한 간결하고 URL에 안전한 형식입니다. JWT는 점으로 구분된 세 개의 base64url 인코딩 부분으로 구성됩니다. Header(알고리즘 및 토큰 유형), Payload(iss, sub, aud, exp, iat 및 사용자 지정 클레임), Signature(토큰의 무결성을 검증하는 암호화 서명)입니다. JWT는 자체 포함형이므로 리소스 서버가 Authorization 서버에 다시 호출하지 않고도 JWT를 검증할 수 있습니다. 이를 통해 성능이 향상되고 상태 비저장 아키텍처를 구현할 수 있습니다. 중요한 보안 요구 사항은 JWT Signature를 항상 검증하고 exp(만료) 및 aud(대상) 클레임을 확인하는 것입니다.

# Decode a JWT (header and payload are just base64 encoded)
import base64, json

jwt = 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNzUwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c'
parts = jwt.split('.')
print('Header:', json.loads(base64.b64decode(parts[0] + '==')))
print('Payload:', json.loads(base64.b64decode(parts[1] + '==')))
# Signature (parts[2]) must be verified with IdP public key!

SAML과 OAuth와 OIDC: 무엇을 언제 사용할 것인가

각 표준을 언제 적용해야 하는지 이해하는 것은 Security+ 시험에서 매우 중요합니다. SAML 2.0: 웹 애플리케이션을 위한 기업용 SSO, 브라우저 기반 흐름, XML Assertion에 사용됩니다. 오래된 기술이지만 기업 환경에 널리 배포되어 있습니다. OAuth 2.0: API Authorization에 사용되며, 타사 앱에 리소스에 대한 제한된 접근 권한을 부여합니다. 사용자를 직접 인증하지는 않습니다. OIDC: OAuth 2.0을 기반으로 구축된 소비자용 및 현대적 기업용 인증(SSO)에 사용됩니다. 사용자를 식별하는 JWT ID 토큰을 반환합니다. 실제로 기업 환경에서는 애플리케이션 SSO에 SAML을, API 및 모바일 인증에 OIDC를 사용하는 경우가 많습니다. 현대적인 클라우드 네이티브 환경에서는 JSON/JWT 형식과 더 나은 모바일 지원 때문에 SAML보다 OIDC를 선호합니다.

페더레이션 공격 벡터

페더레이션 ID 시스템에는 특정한 공격 벡터가 존재합니다. Assertion 재생 공격: 공격자가 SAML Assertion을 가로채 다시 사용하여 접근 권한을 얻습니다. 수명이 짧은 Assertion과 한 번만 사용할 수 있는 Assertion ID를 사용하면 완화할 수 있습니다. XML Signature 래핑(XSW): SAML에서 공격자가 서명된 XML을 조작하여 클레임을 변경하면서 원본 콘텐츠에 대한 Signature는 유효하게 유지하는 경우가 있습니다. JWT 알고리즘 혼동: 서버가 RS256(비대칭)과 HS256(대칭) 알고리즘을 모두 허용하면 공격자는 서버의 공개 키를 HS256의 HMAC 비밀 키로 사용하여 JWT를 위조할 수 있습니다. Header의 알고리즘이 예상한 알고리즘과 일치하는지 항상 검증해야 합니다. 개방형 리디렉터: 리디렉션을 통해 공격자가 제어하는 사이트로 토큰이 탈취되는 것을 방지하려면 OAuth 리디렉션 URI가 정확히 일치해야 합니다.

디렉터리 페더레이션 및 SCIM

기업의 ID 페더레이션에서는 시스템 간에 사용자 ID 데이터를 동기화해야 하는 경우가 많습니다. SCIM(도메인 간 ID 관리 시스템)은 ID 공급자와 연결된 서비스 제공자 간의 사용자 프로비저닝 및 프로비저닝 해제를 자동화하기 위한 REST API 표준입니다. 새 직원이 Azure AD(IdP)에 추가되면 SCIM이 Salesforce, Slack, GitHub 및 기타 SCIM 호환 앱에 해당 직원의 계정을 자동으로 생성합니다. 직원이 퇴사하면 SCIM은 모든 계정을 동시에 비활성화하여 고아 계정이 악용될 수 있는 시간을 없앱니다. SCIM은 SSO 프로토콜(SAML/OIDC)을 보완하여 SSO 프로토콜이 다루지 않는 ID 수명 주기 관리를 처리합니다.

빠른 확인

이 lesson에서 다룬 CompTIA 보안+(SY0-701) 개념에 대한 이해도를 확인해 보십시오.

인터랙티브 레슨에서 답해보세요

lesson 요약

이 lesson에서 배운 내용은 다음과 같습니다. SAML 2.0은 기업용 브라우저 기반 SSO에 XML Assertion을 사용합니다. OAuth 2.0은 API 접근 권한 위임을 위한 Authorization 프레임워크입니다. OpenID 연결은 OAuth 위에 인증(JWT ID 토큰)을 추가합니다. SCIM은 페더레이션 시스템 전반의 ID 수명 주기 관리를 자동화합니다. 이로써 인증 및 Authorization 과정이 완료되었습니다. 다음에는 네트워크 보안 기초를 살펴봅니다.

무료로 시작

AI 튜터와 함께 Security+ Academy을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스: 30
레슨: 120

무료로 학습 시작 전체 코스 보기

자주 묻는 질문

“연합형 ID: SAML, OAuth, OpenID Connect” 강의는 무료인가요?

네 — “연합형 ID: SAML, OAuth, OpenID Connect” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Security+ Academy 강의 전체를 잠금 해제할 수 있습니다. Security+ Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“연합형 ID: SAML, OAuth, OpenID Connect”에서 뭘 배우나요?

SSO, SAML 어설션, OAuth 2.0 흐름, OpenID Connect 토큰이 사용자의 한 번의 인증으로 여러 애플리케이션에 안전하게 접근하도록 지원하는 방식을 학습합니다. 브라우저에서 직접 실행하는 실습 코드로 Security+ Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Security+ Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Security+ Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“연합형 ID: SAML, OAuth, OpenID Connect” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Security+ Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Security+ Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Security+ Academy(으)로 돌아가기