OpenID Connect(OIDC) 연합 인증 구성하기

OpenID Connect(OIDC) 연합 인증 구성하기

Preview 기능 — 공개(Open)

모든 계정에서 사용할 수 있어요.

OpenID Connect(OIDC) 보안 통합은 Snowflake가 ID 공급자(IdP)가 발급한 JSON Web Token(JWT)을 검증하고 사용자 신원 클레임을 Snowflake 사용자에 매핑할 수 있게 해요. OAuth 2.0 위에 구축된 OIDC는 IdP가 사용자를 인증하고 서명된 JWT를 사용해 신원 정보를 Snowflake에 안전하게 전송할 수 있게 해요.

출처: Snowflake 문서

본문

Snowflake OIDC 통합은 두 가지 유형의 OIDC 제공자를 지원해요.

• 관리형 제공자(Managed providers): 예를 들어 OIDC_PROVIDER = 'GOOGLE' 또는 OIDC_PROVIDER = 'MICROSOFT'. Snowflake가 IdP 앱 구성을 처리하므로 최소한의 설정으로 "Google로 로그인" 또는 "Microsoft로 로그인" 같은 소셜 로그인 경험을 쉽게 활성화할 수 있어요.
• 커스텀 제공자(Custom providers): OIDC_PROVIDER = 'CUSTOM'으로 자체 OpenID Connect 호환 IdP 앱(예: Okta, PingFederate, Auth0, Keycloak)을 사용하고 Snowflake에서 일치하는 OIDC 보안 통합을 구성해요. 클라이언트 자격 증명과 issuer URL(엔드포인트 검색에 사용) 또는 명시적 엔드포인트를 포함한 모든 구성 세부정보를 제공해요. Microsoft Entra ID의 경우 자체 앱 등록이 필요하지 않으면 커스텀 통합 대신 관리형 MICROSOFT 제공자를 사용해요.

Snowflake는 OIDC 인증에 PKCE를 사용한 Authorization Code Flow(RFC 7636에 따른 Proof Key for Code Exchange)를 사용해요.

지원되는 로그인 표면

OIDC SSO는 다음 로그인 표면에서 사용할 수 있어요.

• Snowsight로의 브라우저 기반 로그인
• authenticator=OAUTH_AUTHORIZATION_CODE 연결 옵션을 사용하는 클라이언트 연결. 활성화된 OIDC 통합은 브라우저 기반 인증 단계에서 로그인 옵션으로 나타나요.

OIDC는 authenticator=externalbrowser 연결 옵션과 함께 사용할 수 없어요. 외부 브라우저 인증기(Snowflake 드라이버, 커넥터, SnowSQL에서 사용)는 SAML 2.0만 지원해요. 외부 브라우저보다 OAuth 사용을 우선할 것을 권장해요.

OIDC SSO 작동 방식

다음 단계는 사용자가 Snowflake에 로그인할 때의 SP 시작 OIDC 인증 흐름을 설명해요.

• 사용자가 Snowflake 로그인 페이지로 이동해 OIDC 로그인 옵션을 선택해요. 커스텀 제공자의 경우 버튼 라벨은 OIDC_LOGIN_PAGE_LABEL(미설정 시 통합 이름)에서 옵니다. 관리형 제공자의 경우 Snowflake는 공식 제공자 로고와 기본 라벨(예: Sign in with Microsoft)을 표시해요.
• Snowflake가 암호화 보안 파라미터를 생성해요.
  • CSRF 공격을 방지하는 state 파라미터(256비트 임의 값)
  • 토큰 재생 공격을 방지하는 nonce(256비트 임의 값)
  • 인증 코드 교환을 보호하는 PKCE code_verifier와 S256 code_challenge
• Snowflake가 표준 OpenID Connect 인증 요청(response_type=code)으로 사용자의 브라우저를 IdP 인증 엔드포인트로 리디렉션해요.
• 사용자가 IdP에서 인증해요.
• IdP가 인증 코드와 state 파라미터와 함께 사용자를 Snowflake 콜백 URL로 리디렉션해요. 콜백 URL은 통합이 관리형 제공자를 사용하는지 커스텀 제공자를 사용하는지에 따라 달라져요.
  • 커스텀 제공자: IdP가 계정별 콜백 https://<account_url>/oauth2/oidc/callback으로 리디렉션해요.
  • 관리형 제공자(Google 또는 Microsoft): IdP가 전역 Snowflake 관리 콜백 호스트(일반적으로 identity.snowflake.com/oauth2/callback)로 리디렉션한 다음, 흐름을 완료하기 위해 계정별 엔드포인트 /oauth2/oidc/callback으로 리디렉션해요.
• Snowflake가 저장된 값과 state 파라미터를 일정 시간 비교(constant-time comparison)로 검증해요.
• Snowflake가 PKCE code verifier를 포함해 IdP 토큰 엔드포인트에 POST 요청을 보내 인증 코드를 ID 토큰으로 교환해요.
• Snowflake가 ID 토큰을 검증해요.
  • JWKS 엔드포인트에서 가져온 IdP의 공개 키로 JWT 서명을 검증
  • 표준 클레임 검증: iss, aud, azp(여러 audience가 있는 토큰에 azp가 있을 때), exp, iat, nbf, nonce, sub
• Snowflake가 토큰 클레임을 Snowflake 사용자 속성(로그인 이름 또는 이메일 주소)에 매핑해 인증된 사용자를 해석해요.
• Snowflake가 사용자에게 적용 가능한 인증 정책(인증 방법, 통합 허용 목록, MFA 요구사항)과 네트워크 정책을 평가해요.
• 모든 검사가 통과하면 Snowflake가 세션을 만들어요.

관리형 제공자

관리형 제공자의 경우 Snowflake가 필요한 애플리케이션을 ID 공급자에 등록·관리해요. 이를 통해 OIDC 연합 인증 설정이 간소화되며, 제공자에 직접 앱을 등록·유지할 필요가 없어요. 이 방식은 Sign in with Google 또는 Sign in with Microsoft 같은 원활한 소셜 로그인 경험을 최소 구성으로 지원해요.

아래 표는 OIDC 연합 인증에 대해 Snowflake가 현재 지원하는 관리형 제공자를 나열하고 각 제공자의 구성 값을 보여줘요.

제공자	구성 값(OIDC_PROVIDER)
Google	GOOGLE
Microsoft	MICROSOFT

전제 조건

Snowflake에서 OIDC 연합 인증을 구성하기 전에 다음을 확인해요.

• ACCOUNTADMIN 역할 또는 계정에 CREATE INTEGRATION 권한이 있는 역할을 가졌어요.
• 커스텀 제공자의 경우:
  • Snowflake를 나타내는 애플리케이션을 IdP에 등록했어요.
  • IdP에서 클라이언트 ID와 클라이언트 시크릿을 얻었어요.
  • IdP 리디렉션/콜백 URI가 https://<your_account_url>/oauth2/oidc/callback으로 설정됐어요.
  • IdP issuer URL을 알고 있어요(예: Okta의 경우 https://your-org.okta.com).
• Snowflake 사용자가 매핑하려는 IdP 사용자 클레임과 일치하는 적절한 LOGIN_NAME 또는 EMAIL_ADDRESS 속성과 함께 존재해요.

IdP에서 Snowflake 등록(커스텀 제공자)

커스텀 제공자의 경우 Snowflake 보안 통합을 만들기 전에 IdP에 애플리케이션을 등록해요. 단계는 IdP마다 다르지만 일반적으로 다음을 구성해야 해요.

• IdP에서 Snowflake를 나타내는 OpenID Connect(OIDC) 애플리케이션을 만들어요.
• 리디렉션(콜백) URI를 https://<your_account_url>/oauth2/oidc/callback으로 설정해요. 통합을 만든 후 DESC INTEGRATION을 실행해 계정의 자동 생성된 OIDC_REDIRECT_URIS를 보고 등록할 정확한 값을 확인할 수 있어요. 명령이 둘 이상의 URI를 반환하면 사용자가 연결할 수 있는 각 URI를 등록해요.
• IdP 애플리케이션 등록에서 클라이언트 ID와 클라이언트 시크릿을 복사해요. 통합을 만들 때 OIDC_CLIENT_ID 및 OIDC_CLIENT_SECRET에 이 값을 제공해요.
• IdP issuer URL을 기록해요(예: Okta의 경우 https://your-org.okta.com). 이 값을 OIDC_ISSUER에 제공해요.
• IdP 애플리케이션이 Authorization Code Flow를 사용하고 PKCE를 지원하는지 확인해요.

참고(Note): IdP가 실제 클라이언트 ID를 할당하기 전에 placeholder OIDC_CLIENT_ID로 통합을 만들었고, 실제 값이 placeholder와 일치하지 않으면 통합을 삭제하고 올바른 클라이언트 ID로 다시 만들어야 해요. OIDC_CLIENT_ID는 생성 후 변경할 수 없어요.

참고(Note): 관리형 제공자(OIDC_PROVIDER='GOOGLE' 또는 OIDC_PROVIDER='MICROSOFT')의 경우 IdP에 Snowflake를 OAuth 클라이언트로 등록하지 않아요. Snowflake가 OAuth 클라이언트 구성을 관리해요.

OIDC 보안 통합 구성

OIDC 인증은 OIDC 유형의 보안 통합을 통해 구성해요. 계정 수준 제한에 따라 단일 계정에 여러 OIDC 통합이 존재할 수 있어요.

참고(Note): 식별자 우선 로그인이 활성화되지 않으면 계정에서 한 번에 하나의 SSO 통합(SAML2 또는 OIDC)만 ENABLED=TRUE일 수 있어요. 여러 OIDC 통합을 실행하거나 SAML2 통합과 함께 OIDC 통합 하나를 실행하려면 식별자 우선 로그인을 활성화해야 해요.

전체 구문, 파라미터, 예시는 CREATE SECURITY INTEGRATION(OIDC)을 참고해요.

커스텀 OIDC 통합 생성

커스텀 OIDC ID 공급자로 SSO를 구성하려면 CREATE SECURITY INTEGRATION 명령을 사용해 보안 통합을 만들어요.

CREATE SECURITY INTEGRATION <integration_name>
  TYPE = OIDC
  ENABLED = TRUE
  OIDC_PROVIDER = 'CUSTOM'
  OIDC_ISSUER = '<issuer_url>'
  OIDC_CLIENT_ID = '<client_id>'
  OIDC_CLIENT_SECRET = '<client_secret>'
  OIDC_TOKEN_USER_MAPPING_CLAIM = '<claim_name>'
  OIDC_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = '<LOGIN_NAME | EMAIL_ADDRESS>'
  OIDC_LOGIN_PAGE_LABEL = '<label_text>';

완전한 예시는 CREATE SECURITY INTEGRATION (OIDC)을 참고해요.

OpenID Connect 검색에 의존하지 않고 엔드포인트를 명시적으로 지정하려면 OIDC_AUTHORIZATION_ENDPOINT, OIDC_TOKEN_ENDPOINT, OIDC_JWKS_URI를 CREATE 문에 추가해요.

참고(Note): 엔드포인트 파라미터(OIDC_AUTHORIZATION_ENDPOINT, OIDC_TOKEN_ENDPOINT, OIDC_JWKS_URI)를 제공하지 않으면 Snowflake가 issuer의 .well-known/openid-configuration 메타데이터 문서에서 자동으로 검색해요. OpenID Connect 검색을 참고해요. 세 개의 필수 엔드포인트 중 일부만 제공하면 CREATE가 거부돼요.

관리형 OIDC 통합 생성(Google)

Google을 관리형 제공자로 사용하는 경우 Snowflake가 OAuth 클라이언트 구성을 처리하고 Snowflake 로그인 페이지에 공식 Google 로고와 기본 로그인 라벨을 표시해요. 또한 허용된 Google Workspace 호스팅 도메인인 OIDC_ALLOWED_GOOGLE_HOSTED_DOMAINS를 지정해야 해요.

CREATE SECURITY INTEGRATION <integration_name>
  TYPE = OIDC
  ENABLED = TRUE
  OIDC_PROVIDER = 'GOOGLE'
  OIDC_ALLOWED_GOOGLE_HOSTED_DOMAINS = ('mycompany.com');

로그인 시 Snowflake가 ID 토큰의 hd 클레임을 이 목록과 비교하고 그 밖의 Google 계정은 거부해요. ID 토큰에 hd 클레임이 없는 개인·비관리 Google 계정을 허용하려면 리터럴 'personal'을 포함해요.

Google로 Snowflake 계정에 가입했다면 Snowflake가 계정 생성 중 이 통합을 만들고, 가입할 때 사용한 ID 토큰의 hd 클레임에서 허용 목록을 설정하거나, 개인 계정을 사용했다면 'personal'로 설정해요. 나중에 ALTER SECURITY INTEGRATION (OIDC)으로 목록을 변경할 수 있어요.

완전한 Google 예시는 CREATE SECURITY INTEGRATION (OIDC)을 참고해요.

관리형 OIDC 통합 생성(Microsoft)

Microsoft Entra ID를 관리형 제공자로 사용하는 경우 Snowflake가 OAuth 클라이언트 구성을 처리하고 Snowflake 로그인 페이지에 공식 Microsoft 로고와 기본 로그인 라벨을 표시해요. 또한 허용된 Microsoft 테넌트인 OIDC_ALLOWED_MSFT_TENANTS를 지정해야 해요.

CREATE SECURITY INTEGRATION <integration_name>
  TYPE = OIDC
  ENABLED = TRUE
  OIDC_PROVIDER = 'MICROSOFT'
  OIDC_ALLOWED_MSFT_TENANTS = ('a1b2c3d4-e5f6-4789-a012-3456789abcde');

로그인 시 Snowflake가 ID 토큰의 tid 클레임을 이 목록과 비교하고 그 밖의 Microsoft 테넌트는 거부해요. Microsoft의 정적 소비자 테넌트를 통해 로그인하는 개인 Microsoft 계정을 허용하려면 리터럴 'personal'을 포함해요.

Microsoft로 Snowflake 계정에 가입했다면 Snowflake가 계정 생성 중 이 통합을 만들고, 가입할 때 사용한 ID 토큰의 tid 클레임에서 허용 목록을 설정하거나, 개인 계정을 사용했다면 'personal'로 설정해요. 나중에 ALTER SECURITY INTEGRATION (OIDC)으로 목록을 변경할 수 있어요.

완전한 Microsoft 예시는 CREATE SECURITY INTEGRATION (OIDC)을 참고해요.

참고(Note): Snowflake는 관리형 Microsoft OIDC 로그인에 게시자 검증된 멀티 테넌트 Microsoft Entra 애플리케이션("Snowflake Social Login")을 사용해요. 사용자가 Snowflake 홈 테넌트가 아닌 다른 홈 테넌트의 이메일로 로그인하면 Microsoft Entra가 첫 로그인 시 동의 프롬프트를 표시해요. 사용자 또는 홈 테넌트 관리자가 Snowflake가 로그인을 완료하기 전에 요청된 위임 권한(범위)에 동의해야 해요.

관리형 Microsoft OIDC 통합은 ID 토큰의 email 클레임으로 사용자를 매핑해요. 동의 후 email 클레임이 없으면 사용자 해석이 실패해요. 홈 테넌트 관리자가 Snowflake 애플리케이션에 대한 관리자 동의를 부여하거나, 테넌트의 엔터프라이즈 애플리케이션에 선택적 클레임을 구성해 ID 토큰에 email이 포함되도록 해야 할 수 있어요.

관리형 통합(Google과 Microsoft)은 같은 파라미터 제한을 공유해요.

중요(Important): 관리형 제공자의 경우 OIDC_ISSUER, OIDC_CLIENT_ID, OIDC_CLIENT_SECRET, OIDC_SCOPES, 엔드포인트 파라미터, 사용자 매핑 파라미터(OIDC_TOKEN_USER_MAPPING_CLAIM, OIDC_SNOWFLAKE_USER_MAPPING_ATTRIBUTE), OIDC_LOGIN_PAGE_LABEL을 설정할 수 없어요. Snowflake가 이 값을 관리하고, 사용자 매핑을 email 클레임 → EMAIL_ADDRESS로 고정하며, 공식 제공자 로고와 기본 로그인 라벨을 표시해요. 이러한 옵션을 하나라도 설정하면 CREATE 또는 ALTER 문이 실패해요.

허용 목록 옵션은 제공자별이에요. GOOGLE 통합은 OIDC_ALLOWED_GOOGLE_HOSTED_DOMAINS만, MICROSOFT 통합은 OIDC_ALLOWED_MSFT_TENANTS만, CUSTOM 통합은 둘 다 수락하지 않아요. 커스텀 통합의 접근을 제한하려면 ALLOWED_USER_DOMAINS 또는 ALLOWED_EMAIL_PATTERNS를 사용해요.

OIDC 통합 관리

다음 명령을 사용해 OIDC 보안 통합을 관리해요.

• 구성 보기: DESC INTEGRATION. 이 명령은 커스텀 제공자의 IdP에 등록해야 하는 자동 생성된 OIDC_REDIRECT_URIS를 포함한 모든 통합 속성을 반환해요. OIDC_CLIENT_SECRET은 시크릿이므로 결과에서 생략돼요.
• 속성 수정: ALTER SECURITY INTEGRATION (OIDC).
• 통합 제거: DROP INTEGRATION.

경고(Warning): 활성 OIDC 통합을 삭제하면 즉시 모든 사용자가 해당 IdP를 통해 인증하지 못하게 돼요. 인증 정책이 SECURITY_INTEGRATIONS 목록에서 그 통합을 명시적으로 참조하면, 정책이 업데이트될 때까지 삭제가 거부돼요.

복제와 장애 조치

Snowflake는 SAML2 및 OAuth 보안 통합과 같은 장애 조치 그룹 접근 방식을 사용해 OIDC 보안 통합을 소스 계정에서 대상 계정으로 복제하고 장애 조치/장애 복구를 지원해요. 통합 속성은 OIDC_CLIENT_SECRET을 포함해 객체와 함께 복제돼요.

커스텀 제공자의 경우 대상 계정으로 복제한 후 해당 계정의 OIDC_REDIRECT_URIS를 IdP에 등록해요. 관리형 제공자(OIDC_PROVIDER='GOOGLE' 또는 OIDC_PROVIDER='MICROSOFT')는 계정별 리디렉션 URI 등록이 필요하지 않아요.

참고(Note): 커스텀 OIDC 통합은 Client Redirect를 인지하지 못해요. IdP에 등록된 리디렉션 URI는 통합이 생성된 계정에 바인딩돼요. Client Redirect를 통해 보조 계정으로 장애 조치하면 보조 계정의 리디렉션 URI를 IdP에 별도로 등록하거나 관리형 제공자를 사용해요. SAML2 통합은 SAML2_SNOWFLAKE_OTHER_ACS_URLS를 통해 기본·보조 ACS URL을 둘 다 알리지만, OIDC에는 현재 동등한 기능이 없어요.

절차와 세부사항은 여러 계정 간 보안 통합 및 네트워크 정책 복제를 참고해요.

사용자 매핑과 해석

Snowflake가 IdP에서 검증된 ID 토큰을 받으면 인증된 신원을 Snowflake 사용자에 매핑해야 해요. 이것은 두 속성으로 제어돼요.

• OIDC_TOKEN_USER_MAPPING_CLAIM: ID 토큰의 어느 클레임이 사용자 식별자를 포함하는지 지정해요. 여러 폴백 클레임의 경우 순서 있는 목록을 지정해요(예: ('email', 'sub')).
• OIDC_SNOWFLAKE_USER_MAPPING_ATTRIBUTE: 일치시킬 Snowflake 사용자 속성을 지정해요.

관리형 제공자(Google과 Microsoft)의 경우 사용자 매핑은 email 클레임 → EMAIL_ADDRESS로 고정되며 구성할 수 없어요. Microsoft 관리형 통합의 경우 교차 테넌트 동의와 email 클레임 요구사항은 관리형 OIDC 통합 생성(Microsoft)을 참고해요.

토큰 클레임 매핑

다음 표는 OIDC_TOKEN_USER_MAPPING_CLAIM에서 사용할 수 있는 일반적인 ID 토큰 클레임을 설명해요.

클레임	일반적인 값	사용 시점
email	[email protected]	Snowflake 사용자가 이메일 주소로 식별될 때
preferred_username	jsmith	Snowflake 사용자가 IdP 사용자 이름과 일치하는 사용자 이름으로 식별될 때
sub	10239485723	Snowflake 사용자가 IdP의 고유 주제 식별자로 매핑될 때
기타 커스텀 클레임	(다양)	ID 토큰에 있는 다른 이름 클레임

여러 클레임을 순서 있는 목록으로 지정할 수 있어요(예: ('email', 'preferred_username', 'sub')). Snowflake는 나열된 클레임에서 순서대로 비어 있지 않은 값을 모두 추출한 다음, OIDC_SNOWFLAKE_USER_MAPPING_ATTRIBUTE에 대해 각 값으로 사용자 조회를 시도해 첫 번째 성공한 일치를 사용해요. 클레임이 ID 토큰에 없으면 Snowflake는 건너뛰고 다음을 시도해요. 문자열 값 클레임만 지원되며, 비문자열 클레임(숫자, 부울, 객체)은 문자열화되어 일반적으로 어떤 Snowflake 사용자 속성과도 일치하지 않아요. Snowflake는 누락된 클레임을 검색하기 위해 UserInfo 엔드포인트를 호출하지 않아요. 나열된 클레임 중 사용자를 해석하는 것이 없으면 로그인이 실패해요.

CREATE SECURITY INTEGRATION my_oidc
  TYPE = OIDC
  ...
  OIDC_TOKEN_USER_MAPPING_CLAIM = ('email', 'preferred_username', 'sub')
  OIDC_SNOWFLAKE_USER_MAPPING_ATTRIBUTE = 'LOGIN_NAME';

참고(Note): 사용자 일치는 대소문자를 구분하지 않아요. LOGIN_NAME의 경우 조회 전에 클레임 값이 대문자로 정규화돼요(로그인 이름은 계정 내에서 고유). EMAIL_ADDRESS의 경우 Snowflake는 대소문자를 구분하지 않는 조회를 수행하며 검증된 이메일 요구사항의 추가 규칙이 적용돼요.

검증된 이메일 요구사항

EMAIL_ADDRESS에 대해 매핑을 구성하면 이메일 주소는 고유 식별자보다는 공유된 사용자 제공 속성이에요. 검증되지 않거나 중복된 이메일을 통한 계정 탈취를 방지하기 위해 Snowflake는 이메일 기반 해석에 다음 규칙을 적용해요. 이러한 규칙은 LOGIN_NAME 매핑에는 적용되지 않아요.

관리형 제공자의 경우 사용자는 로그인하기 전에 Google Workspace 또는 Microsoft 테넌트에서 이메일을 검증해야 해요. Snowflake는 ID 토큰의 email_verified 클레임을 확인하며, 이메일이 IdP에서 검증되지 않으면 로그인이 실패해요. OIDC_ALLOWED_GOOGLE_HOSTED_DOMAINS 또는 OIDC_ALLOWED_MSFT_TENANTS에 'personal'을 포함하면 두 제공자 모두 개인·비관리 계정을 기본적으로 검증된 것으로 처리해요.

• 일치한 사용자의 이메일이 검증되어야 해요. 기본적으로 이메일이 검증되지 않은 사용자는 이메일 기반 OIDC 매핑으로 로그인할 수 없으며, 로그인은 해석되지 않은 사용자로 실패해요(다른 놓친 조회와 같은 일반 오류). 이메일은 다음 두 가지 중 하나로 검증된 것으로 간주돼요. 사용자가 자신의 사용자 레코드에서 이메일 검증 흐름을 완료했거나, 도메인 검증(SYSTEM$VERIFY_DNS_DOMAIN 사용, SYSTEM$UNVERIFY_DNS_DOMAIN으로 되돌릴 수 있음)을 통해 계정에 대해 사용자의 이메일 도메인이 검증됐어요. 도메인 검증은 도메인별로 정확히 일치해요. example.com을 검증하면 sub.example.com을 포함하지 않아요. 이메일 기반 OIDC 매핑을 소수의 사용자보다 많이 롤아웃할 때는 회사 이메일 도메인을 한 번 검증하는 것이 모든 사용자가 개별 검증 흐름을 완료하게 하는 것보다 훨씬 쉬우며 권장되는 경로예요.
• 검증된 이메일이 중복 주소를 구분해요. 둘 이상의 Snowflake 사용자가 토큰의 이메일 주소를 공유하면:
  • 그중 정확히 한 사용자가 검증된 이메일을 가진 경우 Snowflake가 그 사용자로 해석해요.
  • 둘 이상이 검증된 이메일을 가진 경우 신원이 모호하므로 로그인이 실패해요.
  • 아무도 검증된 이메일을 가지지 않으면 로그인이 실패해요.
  • 모호함을 피하려면 각 이메일 주소가 단일 Snowflake 사용자에 매핑되도록 하거나, 식별자가 고유함이 보장되는 LOGIN_NAME 매핑을 사용해요. 이 규칙은 EMAIL_ADDRESS 매핑에만 적용되므로 LOGIN_NAME 매핑은 같은 Snowflake 사용자가 파일에 검증되지 않은 이메일을 가져도 검증된 이메일 요구사항을 완전히 우회해요.

도메인 또는 이메일 패턴으로 접근 제한

도메인 또는 이메일 패턴 필터를 구성해 어떤 IdP 사용자가 인증하도록 허용할지 제한할 수 있어요. 필터는 식별자 우선 로그인 화면(OIDC 버튼 제공 시)과 IdP가 토큰을 반환한 후(사용자 조회에 사용된 해석된 클레임 값에 대해) 둘 다 적용돼요.

도메인 제한(ALLOWED_USER_DOMAINS):

ALTER SECURITY INTEGRATION my_oidc
  SET ALLOWED_USER_DOMAINS = ('mycompany.com', 'subsidiary.com');

ALLOWED_USER_DOMAINS는 이메일 도메인에 대해 정확한 대소문자 구분 없는 일치를 수행해요. 값 mycompany.com은 [email protected]과 일치하지만 [email protected]이나 [email protected]과는 일치하지 않아요. 도메인별로 접근을 제한하는 권장 방법이에요.

이메일 패턴 제한(ALLOWED_EMAIL_PATTERNS):

ALTER SECURITY INTEGRATION my_oidc
  SET ALLOWED_EMAIL_PATTERNS = ('^[^@]+@mycompany\\.com$', '^admin-.*@subsidiary\\.com$');

중요(Important): ALLOWED_EMAIL_PATTERNS는 하위 문자열로 일치되는(정규식 "find"에 해당하는) Java 스타일 정규식을 수락하며, 전체 문자열 일치가 아니에요. 따라서 앵커가 없는 패턴은 포함하는 값과 일치해요. 예를 들어 mycompany.com은 [email protected]도 허용하고, .는 모든 문자와 일치해요. 항상 패턴을 ^와 $로 앵커링하고 리터럴 마침표(\\.)를 이스케이프해요. 도메인으로만 제한하면 ALLOWED_USER_DOMAINS를 선호해요.

참고(Note): ALLOWED_EMAIL_PATTERNS는 ENABLE_IDENTIFIER_FIRST_LOGIN 계정 파라미터가 활성화되어 있어야 해요. 식별자 우선 로그인이 비활성화된 상태에서 ALLOWED_EMAIL_PATTERNS를 설정하면 feature-not-enabled 오류로 실패해요.

OpenID Connect 검색

Snowflake는 OpenID Connect Discovery 1.0 사양을 사용한 자동 엔드포인트 검색을 지원해요. OIDC_ISSUER URL을 제공하고 엔드포인트 파라미터를 생략하면 Snowflake가 다음에서 IdP 메타데이터를 가져와요.

<OIDC_ISSUER>/.well-known/openid-configuration

Snowflake는 메타데이터 문서에서 다음 엔드포인트를 검색해요.

메타데이터 필드	매핑 대상	필수
authorization_endpoint	OIDC_AUTHORIZATION_ENDPOINT	예
token_endpoint	OIDC_TOKEN_ENDPOINT	예
jwks_uri	OIDC_JWKS_URI	예
userinfo_endpoint	OIDC_USERINFO_ENDPOINT	아니요(저장만, 로그인 시 미사용)

검색이 OIDC_USERINFO_ENDPOINT를 채우면 Snowflake가 통합에 값을 기록해요. 로그인은 이 엔드포인트를 호출하지 않으며, 사용자 해석은 ID 토큰 클레임만 사용해요. 사용자 매핑과 해석을 참고해요.

검색이 실패하거나 메타데이터 문서에 필수 엔드포인트가 없으면 CREATE SECURITY INTEGRATION 명령이 오류와 함께 실패해요.

참고(Note): 세 엔드포인트 파라미터(OIDC_AUTHORIZATION_ENDPOINT, OIDC_TOKEN_ENDPOINT, OIDC_JWKS_URI)를 모두 명시적으로 제공하면 Snowflake가 검색 과정을 건너뛰어요. 이것은 IdP가 잘 알려진 메타데이터 문서를 게시하지 않거나 검색된 값을 재정의해야 할 때 유용해요. 세 필수 엔드포인트 중 일부만 제공하면 거부돼요. Snowflake는 검색을 실행하거나(엔드포인트 미제공) 명시적인 완전한 집합을 수락해요.

인증 정책 통합

OIDC는 Snowflake의 인증 정책 프레임워크와 통합돼요. 인증 정책은 관리자가 특정 사용자나 계정에 허용되는 인증 방법, 통합, 클라이언트를 제한할 수 있게 해요.

OIDC 인증 방법

AUTHENTICATION POLICY는 허용된 인증 방법 목록을 수락해요. 정책의 AUTHENTICATION_METHODS에 OIDC를 추가하면 이 정책에서 OIDC 연합 로그인이 허용된다고 선언해요. ALL은 이미 OIDC를 포함하므로 ALL로 설정된 기존 정책은 정책 변경 없이 OIDC를 자동으로 허용해요.

예시: OIDC와 비밀번호 활성화, 나머지 모두 비허용

CREATE AUTHENTICATION POLICY oidc_or_password
  AUTHENTICATION_METHODS = ('OIDC', 'PASSWORD')
  COMMENT = 'Users may sign in via OIDC SSO or password';

ALTER USER alice SET AUTHENTICATION_POLICY = oidc_or_password;

허용된 통합 제한

SECURITY_INTEGRATIONS 정책 속성을 사용해 정책 범위를 이름으로 특정 OIDC 통합으로 좁힐 수 있어요.

CREATE AUTHENTICATION POLICY engineering_oidc
  AUTHENTICATION_METHODS = ('OIDC')
  SECURITY_INTEGRATIONS = ('GOOGLE_OIDC_INT');

SECURITY_INTEGRATIONS가 설정되면 이 정책에서 나열된 통합만 사용할 수 있어요. 목록에는 SAML2와 OIDC 통합 유형이 모두 허용돼요.

식별자 우선 로그인 필터링

계정에서 식별자 우선 로그인이 활성화되면 로그인 화면에서 사용자에게 제공되는 OIDC SSO 옵션은 사용자의 인증 정책으로 필터링돼요.

• AUTHENTICATION_METHODS가 OIDC를 포함하지 않으면(그리고 ALL이 아니면) OIDC 버튼이 표시되지 않아요.
• SECURITY_INTEGRATIONS가 설정되고 OIDC 통합만 나열하면 해당 통합만 제공돼요.
• SECURITY_INTEGRATIONS가 OIDC가 아닌 통합만 포함하면 Snowflake는 계정 전체 OIDC 목록으로 폴백하며, 이는 기존 SAML 동작과 일치해요.

로그인 이름 일치 확인

IdP가 ID 토큰으로 리디렉션한 후, 사용자가 식별자 우선 프롬프트에서 로그인 이름이나 이메일을 입력했다면 Snowflake는 해석된 Snowflake 사용자가 그 힌트와 일치하는지 확인해요. 해석된 사용자가 입력한 식별자와 일치하지 않으면(그리고 그로부터 찾을 수 없으면) 로그인이 거부돼요. 이는 사용자가 Snowflake 프롬프트에서 한 신원을 입력하고 IdP에서 다른 신원으로 인증하는 것을 방지해요.

OIDC 후 다중 인증

OIDC SSO 로그인 후 Snowflake MFA를 요구하려면 인증 정책의 MFA_POLICY에서 ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'ALL'을 설정해요. 'ALL'을 지정하면 MFA에 등록된 사용자에게 SSO 로그인 후 MFA가 강제돼요. 이것은 OIDC와 SAML 모두에 적용돼요. 자세한 내용은 MFA로 사용자·계정 인증 강화를 참고해요.

예시: MFA를 사용한 OIDC SSO 요구

CREATE AUTHENTICATION POLICY engineering_sso_policy
  AUTHENTICATION_METHODS = ('OIDC')
  SECURITY_INTEGRATIONS = ('GOOGLE_OIDC_INT')
  MFA_ENROLLMENT = 'REQUIRED'
  MFA_POLICY = (
    ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'ALL'
  )
  COMMENT = 'Engineers must use Google SSO with MFA';

ALTER USER alice SET AUTHENTICATION_POLICY = engineering_sso_policy;

OIDC 로그인과 통합 문제를 해결하려면 OIDC 문제 해결을 참고해요.

더 알아보기 (Learn more)

• 연합 인증과 SSO 개요 — 연합 인증 개념
• 인증 정책 — 인증 정책
• CREATE SECURITY INTEGRATION (OIDC) — OIDC 보안 통합 생성