Cloudflare Workers를 위한 오픈 소스 인증·접근 관리 플랫폼으로, OpenID Certified™ 인증을 받았습니다. 엣지 중심 아키텍처에서 인증, 인가, ID 연동을 제공합니다.
1.0 이전 버전입니다. 핵심 프로토콜은 구현되었으며, 운영 환경을 위한 강화와 검증을 진행하고 있습니다.
WebAuthn 패스키 또는 이메일로 받은 6자리 코드로 로그인합니다. 아직 패스키가 없는 사용자에게도 비밀번호 없는 대체 로그인 수단을 제공합니다.
OpenID Connect와 SAML 2.0으로 애플리케이션과 기존 ID 제공자를 연결합니다. 첫 로그인 시 계정을 만들고 외부 ID를 연결할 수 있습니다.
역할(RBAC), 속성(ABAC), 관계(ReBAC)를 기준으로 접근을 제어합니다. 테넌트별 정책에 따라 API로 권한을 확인합니다.
사용자가 늘어나면 Cloudflare D1 용량을 자동으로 확장합니다. 수요를 예측하고 데이터베이스 샤드를 추가하므로 플랫폼을 바꾸지 않고 성장할 수 있습니다.
프로덕트 노트
개인정보를 분리해 장애 조사와 계정 삭제를 지원합니다.
프로덕트 노트
로그인 문제를 조사하다가 볼 필요가 없는 개인정보까지 보게 되는 일. 이 설계는 운영 현장에서 느끼던 그 불편함에서 시작되었습니다.
인증 기반을 운영하다 보면 “특정 사용자가 로그인할 수 없습니다”라는 문의를 받습니다. 원인을 찾으려면 고객 환경에 들어가 해당 계정을 찾아야 합니다.
필요한 정보는 구체적입니다. 계정이 잠겼는지, 마지막 시도가 언제 어느 단계에서 실패했는지, 어떤 경로로 로그인했는지, 패스키 등록이 유효한지 확인하면 됩니다.
이 정보를 확인하는 데 그 사람이 누구인지 알 필요는 없습니다. 그런데 계정을 열면 이름, 이메일 주소, 전화번호, 연결된 계정이 한 화면에 나옵니다. 상태를 보려 했는데 신원까지 함께 보입니다.
이미 화면에 표시되는 정보라면
“보지 마세요”라는 지침만으로는 막을 수 없습니다.
누군가 절차를 어긴 것도 아닙니다. 고객이 요청했고, 정해진 절차대로 조사했습니다. 그래도 정보가 보입니다. 시스템 구조가 그렇게 되어 있기 때문입니다.
규칙과 교육만으로 해결하면 담당자의 기억과 주의에 의존하게 됩니다. Authrim이 개인정보를 별도 데이터베이스에 두는 이유는 이 문제를 구조적으로 해결하기 위해서입니다.
개인을 직접 식별하는 정보는 물리적으로 분리된 데이터베이스에 저장합니다. 나중에 덧붙인 구분이 아니라 데이터 접근 계층부터 분리되어 있습니다.
이렇게 나누면 첫 번째 문제를 해결할 수 있습니다. 잠금 상태, 인증 실패, 기기 정보는 왼쪽만으로 확인할 수 있습니다. 오른쪽에 접근할 권한 없이 조사 권한을 부여하므로 담당자가 일부러 눈을 돌릴 필요가 없습니다.
같은 구조는 감사 대응에도 도움이 됩니다. 이름과 이메일이 어디에 있는지, 삭제할 범위가 어디까지인지 설명할 수 있습니다. 운영 문제를 해결한 구조가 설명도 쉽게 만든 것입니다.
분명히 해야 할 점이 있습니다. 이 분리는 개인정보와 비개인정보를 구분하는 법적 경계가 아닙니다.
Core DB에도 IP 주소, 기기 정보, 세션 이력, 인증 이벤트, 자격 증명 메타데이터, 안정적인 내부 사용자 ID가 들어갑니다. 상황에 따라 이 정보도 개인정보에 해당합니다. 다른 정보와 결합하면 개인을 식별할 수 있기 때문입니다.
Authrim이 구분하는 것은 직접 식별 정보와 운영에 필요한 신원 데이터입니다. 후자만으로 조사할 수 있게 하려는 것이지, 후자를 보호하지 않아도 된다는 뜻이 아닙니다.
따라서 “개인정보는 PII DB에만 있다”는 설명은 정확하지 않습니다. 이름과 이메일 같은 직접 식별 정보를 PII DB에 격리하여, 그 저장소에 접근하지 않고 조사 권한을 부여할 수 있다는 의미입니다.
계정을 삭제하는 작업 자체는 간단합니다. 그 뒤에 따르는 두 가지 요구가 더 어렵습니다.
하나는 삭제했다는 증명입니다. 언제, 누가, 왜 삭제했는지 나중에도 확인해야 합니다. 다른 하나는 일정 기간 재가입을 막는 것입니다.
두 요구 모두 이미 삭제한 사람을 다시 알아보아야 한다는 모순이 있습니다. 직접 식별 정보를 남기면 삭제의 취지와 충돌합니다.
구현의 원칙도 같습니다. 중복 방지에 필요한 지문만 남기고, 보관 기한이 지나면 삭제합니다. 삭제 시각, 실행자, 이유도 기록합니다.
기술적으로 한 가지 덧붙이면, 이메일 주소는 엔트로피가 낮습니다. 단순 해시만 사용하면 사전 공격으로 주소를 찾을 수 있습니다. 복원 불가는 무조건적인 보장이 아닙니다.
Authrim은 비밀 키를 사용하는 HMAC-SHA256 블라인드 인덱스에 키 세대 번호를 기록하여 키 교체를 지원합니다. 키가 없으면 후보 주소의 지문을 다시 계산해 대조할 수 없습니다.
따라서 키의 격리가 이 보호의 전제입니다. 키와 지문을 함께 두면 이 보장은 사라집니다.
로그인 실패 문의로 돌아가 봅시다. 담당자가 알아야 할 것은 인증이 어디서 멈췄는지입니다. 대개 이름이나 전화번호까지 열 필요는 없습니다.
Authrim은 직접 식별 정보를 분리하여 해당 저장소 접근 없이 진단 권한을 줄 수 있도록 합니다. 개인정보가 꼭 필요한 조사에서는 추가 권한을 가진 담당자가 처리합니다.
암호화와 접근 제어로 데이터를 보호하고 감사 로그로 사용을 확인합니다. 그와 함께 담당자가 불필요한 개인정보를 열지 않고 일상적인 조사를 마칠 수 있어야 합니다. 저장소 분리는 이를 매일의 운영에서 출발점으로 삼기 위한 설계입니다.
구현: 저장소와 접근 경계 분리 완료.
검증: 소스 저장소의 자동화 테스트로 지속 확인.
운영 성숙도: 강화 작업 진행 중. Authrim은 pre-1.0 단계입니다.
이 설계는 삭제 절차를 쉽게 해 주지만, 그 자체로 법규 준수를 보장하지는 않습니다. 실제 적합성은 조직의 절차와 계약에도 달려 있습니다.
OP·RP 로그아웃 인증은 무엇을 확인할까요?
프로덕트 노트
사용자는 한 번 로그인하지만 그 과정에서 여러 세션이 만들어집니다. 로그아웃할 때는 어느 세션을 어디까지 종료해야 하는지 살펴야 합니다.
서비스에 “Google로 로그인”을 추가했다고 합시다. 사용자에게는 버튼을 한 번 누른 경험입니다.
하지만 내부에서는 경로에 있는 시스템마다 자신의 세션을 발급하고 보관합니다. Google에 하나, Authrim에 하나, 앱에 하나로 모두 세 개입니다.
어딘가에 세션이 남으면 사용자가 계속 작업하거나 비밀번호 없이 다시 로그인할 수 있습니다.
로그아웃은 완료 문구를 띄우는 것만이 아닙니다.
종료할 범위를 정하고 그 안의 세션을 끝내는 일입니다.
여기서 열쇠는 세션입니다. 액세스 토큰과 리프레시 토큰은 별도 체계이므로 세션 종료가 이미 발급한 토큰을 자동으로 무효화하지는 않습니다. 토큰 폐기는 별도로 처리해야 합니다.
OIDC에서 세션 로그아웃, 토큰 폐기, 상위 IdP의 계정 비활성화는 서로 다른 작업입니다. 이 글은 세션을 다룹니다. 토큰은 토큰 인트로스펙션과 폐기 문서를 참고하세요.
이 연결에서 상위 공급자는 로그인을 제공하고 앱은 로그인을 요청합니다. Authrim의 역할은 어느 쪽을 향하느냐에 따라 달라집니다.
로그인은 경로를 따라 진행되지만 로그아웃은 명시적으로 전달해야 합니다.
상위 세션을 종료해도 Authrim이나 앱의 세션이 자동으로 사라지지는 않습니다. 하위에 종료를 알리고, 수신한 시스템이 대응하는 세션을 종료해야 합니다. 다음 그림은 필요한 알림 방식과 설정이 갖춰진 경우입니다.
| 상황 | 연결이 끊겼을 때 생기는 일 |
|---|---|
| 퇴사 처리 | 인사팀이 접근 권한을 회수해도 노트북의 앱은 계속 열려 있고, 다음 날 아침까지 내부 자료가 보입니다. |
| 공용 단말기 | 매장, 병원, 콜센터에서 이전 사용자가 로그아웃했는데 다른 탭에는 그 사용자의 대시보드가 남아 있습니다. |
| 기기 분실 | ‘모든 곳에서 로그아웃’을 눌렀지만 현재 세션만 종료됩니다. |
| 사고 대응 | 침해된 계정을 차단해도 공격자의 세션은 만료될 때까지 유지됩니다. |
| 감사 | ‘모든 시스템에 로그아웃이 전파됨을 입증해 주세요.’ 제시할 근거가 없습니다. |
로그아웃 버튼이 없거나 화면이 바뀌지 않는 문제가 아닙니다. 실제 적용 범위가 예상보다 좁다는 점 때문에 발견하기 어렵습니다.
하위에 알리는 방법은 두 가지입니다. 그중 브라우저에 의존하는 방법은 제약을 더 많이 받습니다.
Authrim의 인증 범위에는 백채널 알림 수신이 포함됩니다. 수신과 하위 전송은 각각 확인해야 합니다.
Authrim은 상위 공급자에 대해서는 RP, 앱에 대해서는 OP 역할을 합니다. 로그아웃을 전달하려면 두 역할 모두 규격을 따라야 합니다.
OP·RP 로그아웃 프로파일 인증은 두 역할을 확인하는 근거입니다. Authrim은 OpenID Foundation의 공식 적합성 테스트를 사용하는 자체 인증 절차를 통해 양쪽 로그아웃 프로파일 인증을 취득했습니다.
인증은 제출한 구현 버전이 신청한 프로파일의 적합성 테스트를 통과했다는 뜻입니다. 고객 네트워크와 모든 앱의 세션이 즉시 종료됨을 보장하지는 않습니다.
상위 공급자와 앱이 필요한 방식을 지원하고 알림 주소와 세션 매핑을 설정해야 합니다. 상위 계정 비활성화가 반드시 로그아웃 알림을 발생시키지도 않습니다. 배포 환경에서 전달 실패, 재시도, 실패 확인도 검증해야 합니다.
인증 버전과 프로파일은 OpenID Foundation의 Certified OpenID Relying Parties & Logout Profiles 목록에서, 범위는 인증 제도 설명에서 확인할 수 있습니다.
로그아웃한 뒤, 어디에 로그인 상태가 남아 있나요?
공용 단말을 다음 사람에게 넘기거나 퇴사자의 접근을 중단할 때 확인할 범위입니다. Authrim은 상위 IdP와 앱 사이에서 알림을 받고 보냅니다. 인증은 구현의 확인 자료이고, 연결된 시스템의 테스트는 실제 종료 범위를 확인하는 과정입니다.
비밀번호를 저장하지 않고 LDAP·AD와 연동합니다.
프로덕트 노트
비밀번호는 이미 사내 Active Directory에 있습니다. 비밀번호 해시를 복제하거나 외부에서 들어오는 접속점을 새로 공개하지 않고 현대적인 로그인을 추가할 수 있을까요? Authrim Relay는 이를 위한 연결 방식입니다.
직원 계정은 Active Directory에 있습니다. 비밀번호 정책과 만료, 퇴사 시 비활성화도 수년 동안 그곳에서 관리해 왔습니다.
패스키를 도입하고 다중 인증을 정리하며 SaaS SSO를 늘리려 합니다. 첫 단계에서 같은 질문을 만납니다. 비밀번호를 어디에서 검증할 것인가?
비밀번호 해시를 클라우드로 동기화하는 구성도, 내부 디렉터리에 검증을 요청하는 구성도 있습니다. 자격 증명을 어디에 두고, 어느 쪽에서 연결하며, 누가 경로를 운영할지 확인해야 합니다.
WordWarden은 검증을 LDAP/AD에 맡긴 채 경로를 선택하게 합니다. 새 수신 엔드포인트를 공개하고 싶지 않은 조직에는 Authrim Relay의 외부로 나가는 연결을 제공합니다.
Authrim WordWarden은 디렉터리 커넥터입니다. LDAP/AD 가까이에 두는 작은 서비스로, 사용자 이름과 비밀번호를 받아 디렉터리에 확인하고 결과를 반환합니다.
로그인 UI, 세션, 패스키, 이메일 코드, 외부 서비스에 제공하는 인증, 감사 연계, 신원 매핑은 Authrim이 담당합니다. WordWarden은 디렉터리 옆에서 검증만 수행합니다.
연결 방향에 따라 네트워크 설정과 운영할 구성요소가 달라집니다.
WordWarden은 세 가지 연결 방식을 제공합니다. 차이는 조직 네트워크에 수신 지점을 공개해야 하는가입니다.
새 배포에서 수신 접근을 늘리고 싶지 않다면 Relay부터 검토할 수 있습니다. 기존 공개 인프라나 터널을 활용하는 이점도 있습니다. 다음은 구성 선택의 예이며 실제 고객 도입 사례는 아닙니다.
새 공개 서버마다 별도 심사가 필요한 기업이나, 학내 LDAP 네트워크에 외부 연결을 허용하지 않는 대학을 생각해 볼 수 있습니다. WordWarden이 Authrim에 연결하므로 내부에 새 수신 포트를 공개하지 않습니다.
새 공개 엔드포인트나 별도 터널 프로세스가 필요 없습니다. 외부로 나가는 WebSocket 연결을 허용해야 하고 WordWarden과 연결 상태는 감시해야 합니다. 외부 통신 자체를 금지한 네트워크에서는 사용할 수 없습니다.
이미 내부 도구를 Cloudflare Tunnel로 공개하고 cloudflared 업데이트와 경로를 담당하는 팀이 있다면, 수신 포트를 추가하지 않고 기존 절차에 WordWarden을 포함할 수 있습니다.
Authrim 요청이 커넥터에 도달할 호스트 이름과 경로를 설정하고 터널을 관리합니다. 내부 호스트에 직접 수신할 필요는 없지만 요청은 Cloudflare 경로를 통해 전달됩니다.
기업·대학·연구기관의 인프라 팀이 DMZ와 리버스 프록시로 외부 연계를 관리하고 있다면, Authrim이 접근할 HTTPS 지점을 기존 인증서·접근 로그·감시 절차로 운영할 수 있습니다.
별도 터널이나 Relay 연결을 유지하지 않아도 됩니다. 대신 수신 경로 허용과 공개 지점 보호·유지보수를 담당합니다. 공개하는 것은 커넥터의 HTTPS 인터페이스이며 LDAP/AD 포트를 인터넷에 직접 여는 구성이 아닙니다.
모든 방식에서 WordWarden은 LDAP/AD에 접근할 수 있어야 합니다. 학술기관이라는 이유로 방식이 결정되는 것이 아니라 인프라와 네트워크 정책으로 선택합니다.
Relay 모드에서 WordWarden은 내부에서 WebSocket으로 Authrim에 연결합니다. WebSocket은 연결을 유지하여 양쪽 모두 메시지를 보낼 수 있게 하는 방식입니다.
WordWarden은 연결을 유지하며 기다립니다. 로그인이 발생하면 Authrim이 같은 경로로 “이 사용자를 확인해 주세요”라고 요청하고, WordWarden은 내부 디렉터리에서 확인한 결과를 반환합니다.
조직 안에서 전화를 걸어 통화를 유지하면 상대방도 말할 수 있는 것과 비슷합니다. 요청마다 외부에서 내부로 새로 연결할 필요가 없습니다.
따라서 디렉터리 쪽은 이 연결을 위한 URL을 공개하지 않습니다. 새 공개 호스트명·인증서·WAF 관리 부담을 줄입니다. 외부로 나가는 통신 허용, WordWarden 유지보수와 연결 상태 모니터링는 여전히 필요합니다.
차이는 누가 먼저 연결하는가입니다. Direct HTTPS는 조직이 Authrim에서 접근 가능한 지점을 제공합니다. Relay는 내부 WordWarden이 Authrim으로 암호화된 WebSocket(wss)을 연결합니다.
일반적인 상태 기반 방화벽과 NAT는 내부에서 시작한 연결을 추적해 그 연결의 응답 통신을 허용합니다. 따라서 외부의 새 연결을 받는 포트 공개나 포트 포워딩 없이 검증 요청을 받을 수 있습니다.
포트를 전혀 사용하지 않는다는 뜻은 아닙니다. 일반적인 wss는 목적지 TCP 443 포트를 사용합니다. 방화벽이나 프록시에서 Relay로의 외부로 나가는 통신과 지속적인 WebSocket 연결을 허용해야 합니다. 연결이 끊기면 요청을 받을 수 없으므로 상태 감시도 필요합니다.
새 외부 연결을 받을 지점을 줄여도 기존 연결로 검증 요청이 들어옵니다. 상대 인증과 요청 검증은 계속 필요합니다.
외부로 나가는 연결도 상대 인증이 필요합니다. Relay는 커넥터 인증과 목적지 설정 확인을 함께 수행합니다.
WordWarden은 짧은 유효기간의 챌린지에 HMAC으로 응답합니다. 챌린지 ID와 nonce를 포함한 문자열에 서명하고, 목적지 URL의 테넌트·커넥터 ID가 자신의 설정과 일치하는지도 확인합니다.
세 방식 모두 HMAC이 필수입니다. Relay는 수신 노출을 줄이는 것이며 커넥터 인증이나 비밀 정보 관리를 생략하는 수단이 아닙니다.
정확히 구분해야 합니다. 비밀번호가 조직 밖으로 전혀 나가지 않는 것은 아닙니다.
로그인 화면에 입력한 비밀번호는 Authrim을 통과합니다. 정확한 설명은 Authrim과 WordWarden이 저장하지 않는다는 것입니다.
성공 시 결과와 요청 속성 중 커넥터의 로컬 허용 목록에 포함된 항목만 반환합니다. 요청자가 가져갈 범위를 정하는 대신 디렉터리 쪽에서 전달 범위를 결정합니다.
따라서 Authrim 설정만 바꿔 내부 네트워크에서 가져올 속성을 늘릴 수 없습니다.
이 연결은 이행 기간을 위한 것입니다.
LDAP/AD를 비밀번호 원본으로 유지하고 기존 계정으로 로그인하게 하면서 패스키를 점진적으로 등록합니다. 이메일 코드는 복구 경로로 둡니다. 로그인 흐름을 유지하며 인증 방식을 바꿀 수 있습니다.
문서는 LDAP/AD의 비밀번호 해시를 Authrim으로 내보내지 말 것도 명시합니다. 그렇게 하면 전환을 돕는 대신 자격 증명 복제본을 만들게 됩니다.
공개 베타 준비 중. 첫 목표는 v0.1.0-beta.1입니다.
파일럿 용도로, LDAP/AD 주변에 서비스를 운영하고 디렉터리·네트워크·TLS·비밀 관리 경계를 이해하는 조직을 대상으로 합니다. 관리형 디렉터리 서비스는 아닙니다.
Directory Authentication과 Relay를 활성화한 Authrim 0.3.2 이상이 필요합니다. 현재 베타는 설정 변경 시 프로세스 재시작이 필요합니다.
자격 증명 복제나 수신 경로 개방이
유일한 선택은 아닙니다.
디렉터리 가까이에서 검증하고 내부에서 외부로 나가는 연결을 시작하면, 비밀번호 해시 복제나 내부 수신 지점 공개 없이 현대적인 로그인을 제공할 수 있습니다.
그다음 목표는 패스키로의 전환입니다. 디렉터리 연결은 사용자의 로그인을 중단하지 않고 전환을 진행할 기반입니다.
기존 계정을 옮기지 않고 D1을 확장합니다.
프로덕트 노트
사용자가 늘어나는 것은 반가운 일입니다. 하지만 현재 데이터베이스가 언제까지 감당할 수 있을지도 고민하게 됩니다. Authrim은 필요한 시점보다 먼저 새 계정의 저장소를 준비합니다.
Authrim이 사용하는 Cloudflare D1은 데이터베이스 하나당 무료 플랜 500 MB, 유료 플랜 10 GB의 용량 제한이 있습니다. 사용자와 데이터가 늘면 새로운 저장 공간이 필요해집니다.
Authrim은 처음부터 여러 데이터베이스에 계정을 배분할 수 있어, 확장할 때 모든 기존 계정을 옮길 필요가 없습니다. 이 저장 단위를 샤드라고 부릅니다.
기존 계정은 그대로 두고 새 계정의 저장 위치를 늘립니다. 이것이 계정 저장소 확장의 기본입니다.
OAuth 클라이언트와 정책 같은 테넌트 설정, 계정과 개인정보, 이메일로 계정 위치를 찾는 인덱스를 각각 저장합니다.
사용자가 늘어도 모든 데이터베이스를 함께 늘릴 필요는 없습니다. 계정과 검색 인덱스는 건수와 증가 속도가 달라 필요한 곳에 용량을 추가합니다.
새 계정은 해당 테넌트가 사용할 수 있는 샤드에 배정됩니다. 정상 작동하며 목표 대비 할당 비율이 낮은 샤드를 우선합니다.
기준은 디스크 사용률이 아니라 설정한 목표 계정 수까지 얼마나 더 받을 수 있는가입니다. 예를 들어 목표가 10만 개라면 2만 개의 여유를 다음 저장소 준비의 기준으로 삼습니다.
여유가 적어지면 준비한 예비 샤드를 배정합니다. 여러 테넌트가 공유하는 경우와 하나가 전용으로 사용하는 경우 모두 같은 방식입니다.
공유 테넌트
전용 테넌트
공유와 전용 혼합
자동 프로비저닝을 설정하면 등록량이 늘 때마다 운영자가 데이터베이스와 테이블을 만들고 새 등록 위치를 연결할 필요가 없습니다. 용량을 추가할 때마다 기존 계정의 이전 계획을 세울 필요도 없습니다.
운영자는 증설 진행, 실패, 사용량과 비용이 예상 범위인지 확인합니다. 권한 부족이나 서비스 한도는 여전히 해결해야 합니다. 이 역할 분담 아래 Authrim이 다음 저장소를 준비합니다.
2만 계정을 더 받을 수 있어도 하루 100개 증가하는 서비스와 시간당 1만 개 증가하는 서비스의 준비 시간은 다릅니다.
Authrim은 현재 할당량과 최근 등록 속도로 계정 및 검색 인덱스의 향후 용량을 예측합니다. 정기 처리는 1분마다 실행되고, 계정 할당 후에도 예측을 갱신합니다.
이미 생성 중인 샤드도 계산에 포함해, 여러 처리가 같은 부족을 감지하더라도 불필요한 데이터베이스를 중복 생성하지 않도록 합니다.
예비 샤드가 부족하면 Cloudflare 관리 API로 D1을 생성하고 테이블을 준비하며 Worker 접근과 저장 위치를 설정·배포합니다. 읽기와 쓰기를 확인한 뒤 할당 대상으로 사용합니다.
자동 프로비저닝을 활성화하고 D1용과 Workers용 API 토큰을 각각 설정해야 합니다. 자동 실행이 불가능하면 운영자가 설정 도구로 진행합니다.
생성 중 진행 상태를 저장합니다. 일시적인 통신 장애는 그 상태에서 재시도할 수 있습니다. 권한이나 리소스 한도 문제는 원인을 해결한 뒤 재개합니다.
준비가 늦어 수용량이 소진되면 새 등록에 재시도가 필요할 수 있습니다. 미리 준비하는 이유는 이 대기 시간을 줄이기 위해서입니다.
용량 추가와 기존 데이터 이동은 다른 작업입니다. 공유 샤드에서 전용 샤드로 옮길 때는 새 위치뿐 아니라 기존 데이터 복사도 필요합니다.
이전을 시작할지는 운영자가 결정합니다. 승인 후 동기화, 검증, 전환은 Authrim이 진행합니다.
현재 지원하는 배치 변경은 공유에서 전용으로의 이전입니다. 전용에서 공유로 돌아가거나 기존 계정을 자동 재분배하는 기능은 없습니다.
사용이 끝난 샤드 삭제도 운영자의 승인이 필요합니다. 용량 증가만으로 기존 데이터 이동이나 삭제가 자동 시작되지는 않습니다.
2026년 7월 20만 테스트 계정 측정에서 Core는 약 208 MB, PII는 238 MB, Lookup은 426 MB였습니다. 각각 유료 플랜의 단일 데이터베이스 한도 10 GB의 5% 미만입니다. 실제 사용량은 속성과 인덱스에 따라 달라집니다.
기본 목표는 샤드당 10만 계정입니다. 물리적 한도까지 채우는 대신 다음 샤드를 준비할 여유를 둡니다.
Authrim은 pre-1.0이며 장기간 대규모 운영 경험은 앞으로 쌓아 갈 단계입니다. 20만 테스트 계정의 저장 용량 측정과 수백만 명이 매일 사용하는 서비스 운영은 구분합니다.
작은 서비스가 처음부터 대규모 구성을 준비할 필요는 없습니다. 적은 샤드로 시작해 등록 증가에 맞춰 저장 위치를 더할 수 있도록 Authrim에 준비 절차를 담았습니다.
사용자가 늘 때 데이터베이스 이사부터 고민하는 일을 줄이고, 서비스 자체에 더 많은 시간을 쓰도록 하고자 합니다.
2026년 7월 30일, 테스트 계정 20만 개로 측정했습니다. MB는 십진 단위입니다. D1 용량 한도는 Cloudflare 문서를 참고하세요.
K6 Cloud 시험은 대표적인 OIDC 워크로드를 다룹니다. 처리 용량은 부하 형태, Cloudflare 요금제 한도, 저장소, 샤딩 방식에 따라 달라집니다.
시험 보고서 →Authrim은 사용자당 요금을 받지 않습니다. 인프라 비용은 요청 수, CPU 시간, 저장소, 로그에 따라 달라집니다. Cloudflare 비용을 대략적으로 살펴보는 참고 자료이며 운영 견적은 아닙니다.
기준 요금은 Cloudflare Workers 요금이며, 실제 Authrim 사용 패턴을 바탕으로 KV, Durable Objects, D1 비용 계수를 적용합니다.
참고 — 인프라 비용만 포함합니다. 규정 준수, 모니터링, 지원, 운영, 보안 검토, 외부 데이터베이스, 대량의 R2·아카이브 사용은 제외됩니다. 실제 비용은 배포 구성에 따라 달라집니다.
TypeScript 중심 API, JavaScript SDK, 엣지 인증 환경을 평가하고 개발하기 위한 설치 절차를 제공합니다.
직접 운영하며 SAML, SCIM, 감사 로그, 테넌트 경계, 저장소와 로그를 제어합니다. 운영 환경을 위한 강화 작업을 진행하고 있습니다.
사용자당 Authrim 요금 없이 Cloudflare에서 시작하고, 실제 요청 수, CPU, 저장소, 로그 사용량에 맞춰 확장하세요.
OpenID 인증
Authrim v0.4.0
7개 카테고리 · 총 28개 프로파일
카테고리 이름을 누르면 공식 인증 목록이 열립니다.
Basic OP · Implicit OP · Hybrid OP · Config OP · Dynamic OP · Form Post OP · 3rd Party-Init OP
RP-Initiated OP · Session OP · Front-Channel OP · Back-Channel OP
Basic RP · Config RP · Dynamic RP · Form Post RP
RP-Initiated RP · Back-Channel RP
Security Profile: private key + DPoP · OpenID Connect · Message Signing: JAR · Message Signing: JARM · Client Credentials: private key + DPoP
Security Profile: private key + DPoP · OpenID Connect · Message Signing: JAR · Message Signing: JARM
Poll: Private Key · Ping: Private Key
Cloudflare Workers를 위한 오픈 소스 인증 플랫폼을 평가해 보세요. 핵심 프로토콜은 구현되었으며 운영 환경을 위한 강화는 진행 중입니다.