Cloudflare Access 신원 공급자(IdP) 연동 제대로 이해하기

Cloudflare Access로 내부 대시보드를 막아두고 나면, 자연스럽게 다음 질문이 따라옵니다. “그래서 로그인은 대체 누가 처리하는 거지?” Access 설정 화면 어디에도 비밀번호를 저장하는 곳은 없고, 사용자 목록을 직접 만드는 메뉴도 보이지 않거든요. 그런데도 @mycompany.com 직원만 통과시키고, 인턴 그룹은 제외하고, MFA를 강제하는 정책이 멀쩡히 돌아갑니다 🤔

비밀은 Access가 인증을 직접 하지 않는다는 데 있습니다. 대신 외부 신원 공급자(Identity Provider, 이하 IdP)에게 “이 사람이 누구인지” 확인을 맡기고, 그 결과만 받아 정책 판단에 사용하죠. 앞선 글에서 Access의 인가(authorization) 계층 — 정책, JWT 검증, 서비스 토큰 — 을 다뤘다면, 이번 글은 그 앞단에서 “누구인가”를 결정하는 인증·신원 계층, 즉 IdP 연동을 깊이 들여다봅니다.

IdP를 제대로 이해하면 그룹 기반 정책이 왜 그렇게 강력한지, SCIM이 왜 운영을 편하게 만드는지, 그리고 여러 IdP를 섞어 쓸 때 왜 가끔 정책이 이상하게 동작하는지까지 한 번에 풀립니다.

인증은 IdP에, 인가는 Access에

먼저 두 단어를 분리해야 합니다. 인증(authentication)은 “당신이 정말 그 사람이 맞는가”를 확인하는 일이고, 인가(authorization)는 “그래서 이 자원에 접근해도 되는가”를 결정하는 일입니다. 로그인 화면에서 비밀번호나 OTP를 입력해 본인임을 증명하는 게 인증, 그렇게 확인된 신원을 정책에 대입해 통과 여부를 가르는 게 인가죠.

Cloudflare Access는 이 중 인가만 담당합니다. 인증은 외부 IdP에 완전히 위임해요. 사용자가 보호된 도메인에 접속하면 Access는 로그인 화면을 IdP로 넘기고, IdP가 인증을 마친 뒤 “이 사람은 alice@mycompany.com이고, sales 그룹 소속이며, MFA로 로그인했다”는 신원 정보를 돌려줍니다. Access는 그 정보를 받아 정책 엔진에 넣을 뿐이에요.

이 분리가 주는 이점이 큽니다. 비밀번호를 Cloudflare가 보관하지 않으니 유출 위험이 줄고, 회사가 이미 쓰는 IdP(Okta, Google Workspace 등)의 계정 관리, MFA, 퇴사자 처리를 그대로 재사용할 수 있거든요. 새 인증 시스템을 또 만들 필요가 없다는 게 ZTNA 도입의 문턱을 크게 낮춰줍니다.

어떤 IdP를 연동할 수 있나

Access가 지원하는 IdP는 크게 네 부류로 나뉩니다.

• 소셜 IdP — Google Workspace, GitHub, Facebook, LinkedIn 같은 OAuth 기반 공급자. 별도 관리자 계약 없이 바로 붙일 수 있어 개인 개발자나 소규모 팀에 적합합니다.
• 엔터프라이즈 IdP — Okta, Microsoft Entra ID(구 Azure AD), OneLogin, PingID, Authentik 등 SAML이나 OIDC로 연결하는 기업용 SSO. 사용자·그룹 관리가 체계적이라 조직 규모가 커질수록 진가를 발휘합니다.
• Cloudflare 자체 — 사용자가 자신의 Cloudflare 계정으로 로그인하는 방식. 별도 IdP 설정도, 이메일 PIN도 없이 Cloudflare 계정 보안(MFA 포함)을 그대로 활용합니다.
• 일회용 PIN(One-time PIN) — 별도 IdP 없이 승인된 이메일 주소로 인증 코드를 보내는 방식. PIN은 발급 후 10분이 지나면 만료됩니다. 외부 협력 업체처럼 IdP 계정을 만들기 애매한 사용자에게 유용합니다.

Cloudflare는 “모든 SAML·OIDC 공급자와 대부분의 OAuth 공급자를 지원한다”고 밝히고 있어서, 목록에 없는 IdP라도 Generic OIDC나 Generic SAML 커넥터로 연결할 수 있습니다. 표준 프로토콜만 지원하면 거의 다 붙는다고 보면 됩니다.

연동의 기본 흐름은 어느 IdP든 비슷합니다. Cloudflare One 대시보드의 Integrations > Identity providers에서 IdP를 추가하고, 소셜이라면 OAuth 앱의 Client ID와 Secret을, SAML/OIDC라면 메타데이터와 엔드포인트를 입력한 뒤, Test 버튼으로 실제 로그인이 되는지 확인하는 식이죠. 여기서 연동해 둔 IdP가 이후 애플리케이션 정책에서 선택지로 등장합니다.

Cloudflare 자체를 IdP로 쓰기

네 부류 중 Cloudflare 자체를 IdP로 쓰는 방식은 2026년 5월에 추가된 비교적 최신 옵션입니다. 그리고 이때부터 신규 Zero Trust 계정의 기본 IdP가 일회용 PIN에서 Cloudflare로 바뀌었어요.

동작 원리는 단순합니다. 로그인 화면에서 Cloudflare를 선택하면 사용자가 자신의 Cloudflare 계정으로 인증하고, 이미 대시보드에 로그인된 세션이 있다면 그대로 통과합니다. 제3자 IdP를 등록할 필요도, 공유 이메일함으로 PIN을 받을 필요도 없죠. 인증의 안전성은 Cloudflare 계정 자체의 보안(MFA 포함)에 위임됩니다. 본인이 Cloudflare 계정 소유자이고 평소 대시보드에 상주하는 개인·소규모 환경이라면, 셋업이 가장 단출하면서도 일회용 PIN보다 안전한 선택지예요.

연동은 대시보드의 Integrations > Identity providers > Add new에서 Cloudflare를 고르기만 하면 끝납니다. 여기서 한 가지 중요한 옵션이 Restrict to account members인데요.

• 켜면 — 내 Cloudflare 계정의 멤버만 인증할 수 있습니다.
• 끄면 — Cloudflare 계정을 가진 사용자라면 누구나 인증을 시도할 수 있습니다(물론 그 뒤 Access 정책이 다시 한번 걸러냅니다).

이 옵션을 끈 채로 두고 정책에서 이메일 도메인만 거는 실수를 하면 의도보다 넓게 열릴 수 있으니, 사내용이라면 켜두는 편이 안전합니다. 이와 짝을 이루는 게 정책 쪽의 Cloudflare Account Member 셀렉터입니다. 정책에서 이 셀렉터를 쓰면 “이 Cloudflare 계정의 멤버인가”를 조건으로 삼을 수 있고, 계정 ID를 비워두면 현재 계정을, 다른 계정 ID를 넣으면 교차 계정(cross-account) 접근까지 표현할 수 있어요.

IdP가 넘겨주는 신원 정보

IdP 연동의 핵심은 “로그인이 된다”가 아니라 “어떤 정보가 함께 넘어오느냐”입니다. 인증이 끝나면 IdP는 사용자 이메일뿐 아니라 그룹 소속, 인증 방법(비밀번호인지, MFA를 거쳤는지, 어떤 종류인지), 그리고 부서, 역할, 근무지 같은 속성을 함께 Access에 전달합니다. 이 정보가 곧 정책 엔진의 재료가 돼요.

그래서 Access 정책이 표현할 수 있는 조건의 범위는 사실상 IdP가 넘겨주는 정보에 의해 결정됩니다. IdP가 그룹 정보를 보내주지 않으면 그룹 기반 정책을 쓸 수 없고, MFA 여부를 알려주지 않으면 “MFA 인증자만 통과” 같은 조건도 걸 수 없죠. 정책이 원하는 만큼 정교해지려면, 그 전에 IdP 연동에서 필요한 속성이 제대로 흘러오도록 맞춰두는 게 먼저입니다.

OIDC를 쓴다면 IdP가 보내는 클레임(claim)을, SAML을 쓴다면 속성(attribute)을 Access가 읽어 들이는데, 어떤 클레임과 속성을 신원에 매핑할지 대시보드에서 지정할 수 있습니다. 예를 들어 IdP가 부서 정보를 department라는 커스텀 클레임으로 보낸다면, 이를 매핑해 두고 정책에서 활용하는 식이에요. OAuth나 OIDC의 토큰 구조에 익숙하다면 이 부분이 한결 자연스럽게 다가올 겁니다.

그룹으로 정책을 단순하게

IdP가 넘겨주는 정보 중에서도 그룹은 특히 중요합니다. 사용자 한 명 한 명을 정책에 직접 적는 대신, IdP에 이미 존재하는 그룹을 그대로 조건으로 쓸 수 있거든요.

생각해 보면 당연합니다. “영업팀 전원이 Salesforce에 접근 가능”이라는 정책을, 영업팀 50명의 이메일을 일일이 나열해서 만들 수는 없잖아요. 대신 IdP의 sales 그룹을 정책 조건으로 걸어두면, 그 그룹에 사람이 들어오고 나가는 변화가 자동으로 정책에 반영됩니다. 신입이 입사해 sales 그룹에 추가되는 순간 별도 작업 없이 접근 권한이 생기고, 퇴사로 그룹에서 빠지면 권한도 사라지죠. 정책 자체는 한 줄 그대로인데 말이에요.

이게 IdP 연동을 단순한 로그인 위임 이상으로 만드는 지점입니다. 신원과 그룹이라는 “이미 회사가 관리하고 있는 자산”을 인가 결정에 그대로 끌어 쓰는 것이라, 권한 관리의 단일 출처(single source of truth)가 IdP 한 곳으로 모이거든요.

SCIM으로 사용자·그룹 자동 동기화

그런데 여기서 한 가지 빈틈이 있습니다. IdP의 그룹 정보는 기본적으로 사용자가 “로그인하는 순간”에만 Access로 전달됩니다. 그러면 누군가를 IdP에서 그룹에서 빼거나 계정을 비활성화해도, 그 사람이 다시 로그인하기 전까지는 기존에 발급된 세션이 살아 있을 수 있어요. 퇴사자 처리 같은 민감한 상황에서는 이 시차가 문제가 됩니다.

이 빈틈을 메우는 게 SCIM(System for Cross-domain Identity Management)입니다. SCIM을 활성화하면 IdP에서 사용자와 그룹이 생성, 수정, 삭제될 때 Access가 실시간으로 동기화해 주거든요. 로그인을 기다릴 필요 없이, IdP에서 계정을 비활성화하면 Access 쪽 세션도 곧바로 끊어낼 수 있습니다.

현재 Okta, Microsoft Entra ID, Authentik 등이 SCIM 프로비저닝을 정식 지원합니다. 엔터프라이즈 IdP를 연동한다면 SCIM도 함께 켜두는 걸 권장하는데, 입·퇴사 라이프사이클이 자동으로 관리되어 “퇴사했는데 아직 접근되네?” 같은 사고를 막아주기 때문이에요. 그룹 기반 정책의 신선도를 보장하는 장치라고 보면 됩니다.

여러 IdP를 함께 쓸 때 주의할 점

하나의 애플리케이션에 IdP를 여러 개 활성화할 수도 있습니다. 직원은 Okta로, 외부 협력 업체는 일회용 PIN으로 들어오게 하는 식이죠. 로그인 화면에서 사용자가 자기 방법을 고르게 되는데, 여기서 자주 놓치는 함정이 하나 있습니다.

같은 사람이 평소에는 Okta로 로그인하다가 어느 날 일회용 PIN으로 로그인하면, Access는 더 이상 그 사용자의 Okta 그룹 소속을 평가하지 않습니다. 신원 정보는 “어떤 IdP로 인증했는가”에 묶여 오기 때문이에요. PIN으로 들어온 세션에는 Okta가 알려주던 sales 그룹 정보가 아예 없으니, 그룹 조건으로 만든 정책이 갑자기 통과하지 못하는 상황이 벌어집니다.

그래서 그룹 기반 정책을 운영한다면, 그 그룹 정보를 제공하는 IdP로 로그인했을 때만 정책이 의도대로 동작한다는 점을 염두에 둬야 합니다. 여러 IdP를 열어둘 때는 “이 정책이 의존하는 속성을 모든 로그인 경로가 제공하는가”를 한 번씩 점검하는 습관이 필요해요. 단일 SSO만 쓰는 환경이라면 아예 IdP를 하나만 활성화하고 Instant Auth를 켜서 로그인 방법 선택지를 없애는 게 이런 혼란을 줄이는 길입니다.

자주 만나는 함정

IdP 연동에서 흔히 부딪히는 지점을 몇 가지 정리해 보겠습니다.

가장 잦은 건 그룹 정보가 안 넘어오는 경우입니다. IdP 쪽에서 그룹을 토큰에 포함하도록 설정하지 않았거나, 매핑이 누락되면 Access는 그룹을 받지 못합니다. 그룹 기반 정책이 아무도 통과시키지 못한다면 먼저 IdP가 그룹 클레임이나 속성을 실제로 보내고 있는지부터 확인하세요. 대시보드의 Test 기능으로 로그인해 보면 어떤 정보가 넘어오는지 점검할 수 있습니다.

그다음으로 SCIM을 켜지 않은 채 퇴사자 처리를 IdP에서만 하는 경우입니다. 앞서 봤듯 그룹 변경은 다음 로그인 때 반영되므로, 즉시 차단이 필요하면 SCIM을 켜거나 세션 지속 시간을 짧게 두어야 합니다.

마지막으로 일회용 PIN을 무심코 함께 열어두는 경우예요. 편의를 위해 PIN을 켜두면, 그룹 기반 정책을 우회하는 로그인 경로가 생기는 셈입니다. 보안이 중요한 애플리케이션이라면 어떤 로그인 방법을 허용할지 의식적으로 좁혀두는 게 좋습니다.

마치며

Cloudflare Access의 IdP 연동은 “인증은 우리가 잘하는 IdP에 맡기고, 그 결과만 받아 인가에 쓴다”는 깔끔한 분업 구조입니다. 비밀번호를 따로 보관하지 않고, 회사가 이미 관리하는 신원과 그룹을 그대로 정책에 끌어 쓰니, 권한 관리가 IdP 한 곳으로 모이는 게 가장 큰 장점이에요.

처음에는 소셜 IdP나 Cloudflare 자체 IdP로 가볍게 시작하고, 조직이 커지면 엔터프라이즈 IdP에 SCIM을 붙여 그룹 기반 정책과 자동 프로비저닝으로 확장하는 게 현실적인 경로입니다. 여기서 만들어진 신원 정보가 결국 Cloudflare Access의 정책 엔진과 JWT 클레임으로 이어지니, 두 글을 함께 읽으면 인증부터 인가까지 전체 그림이 맞춰질 거예요. 사설망 자원까지 보호하려면 Cloudflare Tunnel과 묶는 조합도 살펴보시길 권합니다.

더 자세한 IdP별 설정은 Cloudflare 신원 공급자 공식 문서를 참고하세요.