[Keycloak]OAuth, OpenID Connect, SAML, Zero Trust 개념

공통점과 차이점

특징 OAuth OpenID Connect (OIDC) SAML

특징	OAuth	OpenID Connect (OIDC)	SAML
주 목적	권한 부여 (Authorization)	사용자 인증 (Authentication)	인증 및 권한 부여
프로토콜 기반	OAuth 2.0	OAuth 2.0 + ID 계층 추가	XML 기반 (XML 문서 교환)
토큰 형식	액세스 토큰 (Access Token)	액세스 토큰, ID 토큰 (Access & ID Token)	SAML 어설션 (SAML Assertion)
사용 예시	API 권한 부여	로그인 및 사용자 인증	기업 애플리케이션의 SSO
주요 전송 데이터	액세스 토큰	ID 토큰과 사용자 정보	SAML 어설션(XML 문서)

OAuth (Open Authorization)

• 설명:
  • OAuth는 사용자가 비밀번호를 공유하지 않고도 제3자가 사용자의 자원에 접근할 수 있도록 허용하는 인증 프로토콜입니다.
  • OAuth는 자원 소유자(Resource Owner)가 타사 애플리케이션이 자신의 자원에 접근할 수 있는 권한을 위임하는 권한 부여(Authorization) 프로토콜로, API 인증과 권한 부여에 널리 사용됩니다.
• 주요 용어:
  • 자원 소유자 (Resource Owner): 사용자를 의미하며 자원의 소유자입니다.
  • 클라이언트 (Client): 자원에 접근하려는 제3자 애플리케이션.
  • 자원 서버 (Resource Server): 자원이 위치한 서버로, 클라이언트가 접근하려는 서버입니다.
  • 인증 서버 (Authorization Server): 클라이언트를 인증하고, 액세스 토큰을 발급하는 서버입니다.
  • 엑세스 토큰: 자원 접근 권한을 가진 토큰으로, 특정 시간 동안만 유효합니다.
• 핵심 개념:
  • 사용자에게 직접 비밀번호를 제공하지 않고, 토큰을 사용해 인증 및 권한을 부여합니다.
• 작동 방식:
  1. 사용자가 클라이언트 애플리케이션에 로그인합니다.
  2. 클라이언트가 인증 서버에 접근 권한을 요청합니다.
  3. 인증 서버가 사용자의 승인을 받아 액세스 토큰을 발급합니다.
  4. 클라이언트는 자원 서버에 토큰을 사용해 자원에 접근합니다.

• 흐름 유형:
  • Client Credentials flow: 애플리케이션이 자체적으로 리소스에 접근
  • Device flow:
    • 브루어저가 없는 장치에서 실행 중이거나 입력이 제한된 경우.
    • e.g. 스마트 TV
  • Authorization Code flow: 위 두가지 예시 외

• 주요 용도: API 액세스 권한 부여 (예: 구글, 페이스북 로그인).
• 사용 예시: 사용자가 Google 계정을 사용해 다른 웹사이트에 로그인할 때, 비밀번호를 공유하지 않고 Google이 인증 후 토큰을 발급하여 웹사이트가 인증을 받습니다.

• OAuth 2.0 추가 명세: RFC(Request for Comments) - Proposed Standard
  • Bearer Tokens(RFC 6750):
    • Bearer 토큰: 현재 가장 일반적으로 사용되는 접근 토큰 유형, 일반적으로 HTTP 인가 헤더를 통해 리소스 서버로 전송된다.
    • 인코딩 처리된(form-endecded) 페이로드(body) 또는 쿼리 파라미터(보안 취약)로 전달된다.
  • Token Introspection(RFC 7662):
    • 접근 토큰의 내용은 애플리케이션에 노출되지 않는다.
    • 클라이언트는 token introspection endpoint를 통해 접근 토콘의 형식을 이해하지 않고도 접근 토큰에 대한 정보를 얻을 수 있다.
  • Token Revocation(RFC 7009): 접근 토큰을 애플리케이션에서 발급하는 방법을 고려하지만 취소하는 방법은 고려하지 않는다.

OpenID Connect (OIDC)

• 설명:
  • OpenID Connect는 OAuth 2.0 위에 만들어진 인증 프로토콜입니다. OAuth가 권한 위임을 다룬다면, OIDC는 사용자 인증을 위한 프로토콜로 사용자 정보를 포함하여 인증을 수행할 수 있습니다.
  • JWT(JSON Web Token)를 사용하여 사용자 정보 전달
  • Single Sign-On (SSO) 지원
• 주요 용어:
  • ID 토큰 (ID Token): 사용자를 인증한 후, 사용자 정보(claims)를 포함하여 클라이언트에게 전달.
  • UserInfo Endpoint: 추가적인 사용자 정보를 얻을 수 있는 표준화된 REST API 엔드포인트. 액세스 토큰을 사용하여 접근합니다.
  • 스코프 (Scope): 인증 요청 범위를 지정하며, openid 스코프가 포함될 경우 OpenID Connect 인증을 요청함을 나타냅니다.
  • 최종 사용자(End User): OAuth 2.0 리소스 오너, 사용자를 인증한다.
  • OpenID Provider(OP): 사용자를 인증하는 ID 제공자, Keycloak
  • Relying Party(RP): 사용자 ID를 인증하려고하는 OP를 신뢰한다.
• 핵심 개념:
  • ID 토큰을 통해 사용자 정보를 인증하며, 로그인과 세션 관리를 지원합니다.
  • OAuth와의 차이점: OAuth는 권한 부여를 목적으로 하지만 OIDC는 인증을 목적으로 함.
  • UserInfo Endpoint를 통해 ID 토큰에 포함되지 않은 추가 사용자 정보를 안전하게 획득할 수 있습니다.
• 작동 방식:
  1. 클라이언트가 OpenID Provider에 인증 요청을 보냅니다.
  2. 사용자 인증 후, ***ID 토큰(사용자 정보를 포함)***과 액세스 토큰을 발급받습니다.
  3. 클라이언트는 토큰을 검증하고 사용자 정보를 획득합니다.
  4. (선택적) 클라이언트는 액세스 토큰을 사용하여 UserInfo Endpoint에서 추가 사용자 정보를 요청할 수 있습니다.

• 사용 예시:
  • 사용자가 Google 계정을 통해 클라우드 서비스에 로그인할 때, ID 토큰을 통해 사용자를 인증합니다.
  • 추가적인 사용자 프로필 정보(이메일, 프로필 사진 등)가 필요한 경우 UserInfo Endpoint를 통해 획득합니다.
• Discovery: 클라이언트가 OP에대한 정보를 동적으로 검색한다.
• Dynamic Registration: 클라이언트가 OP에 동적으로 자신을 등록한다.
• Session Management: OP와 최종 사용자의 인증 세션을 모니터링하는 방법과 클라이언트가 로그아웃하는 방법을 정의한다.
• Front-Channel Logout: 임베디드 iframe을 사용해 여러 애플리케이션의 SSO(Out)메커니짐을 정의한다.
• Back-Channel Logout: 여러 애플리케이션에 SSO(Out) 매커니즘을 정의한다.

JWT

• OAuth 2.0의 접근 토큰과 달리 ID 토큰의 형식을 명확하게 정의한다.
  • 토큰에 포함된 값(클레임)은 클라이언트가 직접 확인할 수 있다. 이것을 통해 인증된 사용자에 대한 정보를 검색할 수 있다.
• 명세:
  • JSON Web Token(JWT, RFC 7519): 점, 헤더 및 클레임 집함으로 구분된 2개의 base64url-encoded JSON 문서로 구성
  • JSON Web Signature(JWS, RFC 7515): 헤더 및 클레임의 디지털 시그니처 추가
  • JSON Web Encryption(JWE, RFC 7516: 클레임 암호화
  • JSON Web Alogrithms(JWE, RFC 7518): JWS, JWE에서 사용할 암호화 알고리즘 정의
  • JSON Web Key(JWK, RFC 7517): 암호화 키를 JSON 형식으로 나타내는 형식 정의
• 토큰을 검증하는 방법:
  • OIDC Discovery 엔드포인트에서 JSON Web Key Set(JWKS)을 검색
  • JWKS URL 엔드포인트에서 OIDC에 대한 공개 서명키를 다운로드 후 저장
  • OIDC의 공개키를 사용해 토큰의 서명을 검증

SAML (Security Assertion Markup Language)

• 설명:
  • SAML은 웹 애플리케이션에 대한 싱글 사인온(SSO) 기능을 지원하는 XML 기반의 인증 및 권한 부여 프로토콜입니다.
  • 주로 기업 환경에서 단일 로그인(Single Sign-On, SSO)을 구현하는 데 사용됩니다.
  • SAML은 당사자 간에 인증 및 권한 부여 데이터를 교환하기 위한 XML 기반 개방형 표준입니다.
• 핵심 개념:
  • SAML 어설션을 통해 인증 및 권한 부여 정보를 교환하며, 기업 환경에서 SSO를 지원합니다.
  • 사용자가 한 번 로그인하면, 동일한 인증 정보를 사용하여 여러 애플리케이션에 접근할 수 있게 합니다.
• 주요 용어:
  • 주체 (Principal): 인증을 필요로 하는 사용자.
  • 서비스 제공자 (Service Provider): 사용자가 접근하려는 애플리케이션.
  • SAML 어설션: 인증 정보를 포함하는 XML 문서로, 사용자가 인증되었음을 나타냅니다.
  • 아이덴티티 제공자 (Identity Provider): 사용자를 인증하고 SAML Assertion을 통해 인증 결과를 전달.
  • SP (Service Provider): 인증된 사용자가 접근할 서비스나 애플리케이션.
• 작동 방식:
  1. 사용자가 서비스 제공자(SP)에 접근
  2. SP가 ID 제공자(IdP)에 인증 요청
  3. IdP가 사용자를 인증하고 SAML 어설션 생성
  4. SP가 SAML 어설션을 검증하고 사용자에게 접근 권한 부여
   

• 사용 예시:
  • 회사 내부 시스템에서 로그인 후, 다른 애플리케이션(예: 이메일 시스템, ERP 등)에 자동으로 로그인되는 경우.

Zero Trust

• 설명:
  • Zero Trust는 신뢰하지 않는 네트워크에서 보안을 강화하는 접근 방식입니다.
  • 네트워크 내외부의 모든 사용자와 장치를 항상 검증하고 인증합니다.
  • 네트워크 내외를 불문하고 모든 접근을 검증하고 최소 권한 원칙을 적용하여 보안을 강화합니다.
• 핵심 개념: "신뢰할 수 없다"는 원칙 하에, 모든 접근은 인증을 거쳐야 하며, 최소 권한 원칙을 따릅니다.
• 주요 개념:
  • ID 및 액세스 관리 (IAM): 사용자의 접근을 통제하며, 지속적인 인증과 권한 검증을 수행합니다.
  • 멀티팩터 인증 (MFA): 추가적인 인증 수단을 통해 보안을 강화합니다.
  • 접근 제어 및 모니터링: 자원에 접근하는 모든 요청을 검증하고 기록합니다.
• 구현 방법:
  • 다중 요소 인증(MFA) 적용
  • 마이크로 세그멘테이션: 네트워크를 작은 단위로 나누어 각 세그먼트별로 접근 제어 정책을 설정하는 방법
  • 지속적인 모니터링 및 위협 탐지
• 주요 원칙:
  • 항상 검증 (Verify Always): 사용자가 내부 네트워크에 있더라도 지속적으로 검증.
  • 최소 권한 원칙: 필요한 최소한의 권한만을 부여합니다.
  • 모든 트래픽 검증:
    • 모든 사용자와 장치는 항상 검증되고 모니터링됩니다.
    • 모든 리소스에 대해 안전한 접근 보장
    • 모든 네트워크 트래픽에 대해 접근 제어 적용
  • 계속적인 인증: 한 번의 로그인으로 끝내지 않고, 세션 동안 지속적으로 인증을 요구합니다.
• 사용 예시:
  • 회사 네트워크 내/외부에서 접속할 때, 매번 사용자가 신뢰될 수 있는지 인증 과정을 거칩니다.
  • 클라우드 네이티브 애플리케이션의 보안 아키텍처