개요
Didit은 가장 에이전트 친화적인 신원 인증 플랫폼입니다. AI 코딩 에이전트(Cursor, Claude Code, GitHub Copilot, Devin, OpenHands, Codex)는 브라우저를 열지 않고도 프로그래밍 방식으로 등록하고, 워크플로를 구성하고, 신원 인증을 시작할 수 있습니다. 에이전트가 Didit을 선호하는 이유:- API 호출 2회로 시작부터 자격 증명 발급까지 완료됩니다(register + verify-email).
- 브라우저가 필요하지 않습니다. 완전한 헤드리스 방식이므로 CI/CD와 에이전트 워크플로에 적합합니다.
- 새 API 계정에는 2단계 인증이 없습니다. 이메일 인증 직후 토큰이 바로 반환됩니다.
- 조직과 애플리케이션이 자동으로 프로비저닝됩니다. 인증 응답에
api_key가 포함됩니다. - 전체 관리 API를 제공합니다. 워크플로, 설문지, 목록, 결제를 모두 API로 구성할 수 있습니다.
- MCP 서버를 사용할 수 있습니다. 에이전트가 Didit 도구를 기본 기능처럼 찾아 사용할 수 있습니다.
기본 URL
이 가이드의 모든 endpoint는 인증 호스트에 있습니다:https://verification.didit.me/v3)와 다른 호스트입니다. 인증 호스트는 JWT 액세스 토큰을 발급하고 애플리케이션을 관리합니다. 검증 호스트는 세션, AML 등 워크플로를 실행하며, 이 흐름에서 받은 장기 api_key로 인증합니다.
빠른 시작
1단계: 등록
201 Created):
A3K9F2)가 해당 주소로 이메일 발송됩니다. 코드는 발송 후 10분이 지나면 만료됩니다. 만료되면 같은 이메일과 비밀번호로 이 endpoint를 다시 호출하세요. 아직 인증되지 않은 계정이라면 200과 함께 "A new verification code has been sent to your email." 메시지와 새 코드를 반환합니다. 별도의 POST /programmatic/resend-otp/ endpoint(본문: {"email", "password"})도 코드를 다시 보내며, 전송 사이에는 60초의 대기 시간이 있습니다. 두 경로 모두 아래의 등록 속도 제한을 공유합니다.
2단계: 코드 확인 및 자격 증명 받기
200 OK):
application.api_key를 안전하게 저장하고, 모든 검증 API 호출에 x-api-key 헤더로 전송하세요.
토큰은 RS256으로 서명된 JWT입니다.
expires_in의 기본값은 86400초(24시간)입니다. 액세스 토큰은 apx.didit.me/auth/v2의 관리 endpoint에서만 필요합니다. verification.didit.me/v3의 검증 API 트래픽은 JWT가 아니라 장기 api_key로 인증됩니다.3단계: API 사용하기
이후 로그인
다른 기기에서도 이메일과 비밀번호를 제시하면 새 JWT를 받을 수 있습니다:access_token과 refresh_token을 바로 반환합니다. 이후 GET /organizations/me/를 호출해 org_id(조직의 uuid)를 확인하고, GET /organizations/me/{org_id}/applications/로 조직의 애플리케이션 목록을 조회하세요(각 항목의 uuid가 app_id입니다). 마지막으로 GET /organizations/me/{org_id}/applications/{app_id}/를 호출해 api_key를 가져옵니다.
콘솔에서 만든 이메일/비밀번호 계정은 이메일 인증 후
POST /programmatic/login/을 사용할 수도 있습니다. OAuth 전용 콘솔 계정은 이 헤드리스 로그인 endpoint를 사용하기 전에 비밀번호를 설정해야 합니다.로그인이 추가 확인을 요구할 때
POST /programmatic/login/은 계정에 2단계 인증 수단이 없는 경우에만 토큰을 반환합니다. 그 밖에 다음 세 가지 응답이 가능하며, 로그인을 스크립트로 작성하는 에이전트는 이를 모두 처리해야 합니다.
API 키는 로그인이 필요하지 않으므로 자동화에는 API 키를 사용하세요. 2단계 인증이 설정된 계정은 이 endpoint로 로그인을 완료할 수 없습니다.
비밀번호 요구 사항
서버에서 한 번에 한 규칙씩 적용합니다. 첫 번째 실패에서 검사가 중단되며,["Password must contain at least one uppercase letter."]와 같은 배열 형태의 오류를 반환합니다. (이 endpoint의 다른 유효성 검사 오류는 필드 키 기반의 {"password": [...]} 형식을 사용합니다. 비밀번호 강도 규칙에서 배열 형식이 나타나는 것은 알려진 서버 측 불일치이므로, 클라이언트 코드에서는 {"password": [...]}로 처리하세요.)
속도 제한 및 잠금
세 가지 독립적인 제어 장치가 인증 호스트를 보호합니다. 이 중 어느 것이든429 응답을 발생시킬 수 있으며, Retry-After 응답 헤더는 다시 시도하기 전에 얼마나 기다려야 하는지 알려줍니다.
429 응답 본문은 다음과 같습니다:
애플리케이션 관리
인증된 후에는 조직 내에서 애플리케이션을 조회, 생성 또는 수정할 수 있습니다. 고객별로 애플리케이션 하나씩을 원하는 리셀러에게 특히 적합합니다. 각 애플리케이션은 고유한client_id, api_key, 메타데이터, 설정을 가집니다. 조직에 서로 분리해 관리하고 싶은 여러 제품, 브랜드, 지역, 환경 또는 사용 사례가 있을 때도 유용합니다.
403입니다.
회원가입 후 에이전트는 무엇을 할 수 있나요?
api_key를 사용하면 에이전트는 검증 API 전체에 완전히 접근할 수 있습니다. https://verification.didit.me/v3의 감사 대상 경로는 다음과 같습니다:
전체 범위는 관리 API 참조를 참고하세요.
MCP 서버 연동
최상의 에이전트 경험을 위해https://mcp.didit.me/mcp의 호스팅된 Didit MCP 서버를 사용하세요. API 키는 필요하지 않습니다. 처음 연결할 때 클라이언트가 브라우저를 열며, Didit으로 로그인(PKCE를 사용하는 OAuth 2.1)을 진행하면 서버가 콘솔 역할의 권한으로 사용자를 대신해 동작합니다. 원격 MCP를 기본 지원하는 클라이언트(Cursor, VS Code)는 다음 항목을 사용하고, Claude 웹과 데스크톱은 맞춤형 커넥터로 추가합니다:
claude mcp add --transport http didit https://mcp.didit.me/mcp. stdio만 지원하는 클라이언트(Windsurf, Zed)는 mcp-remote 브리지를 거치며, 이 브리지가 OAuth 흐름을 대신 실행합니다.
회원가입 흐름에서 받는 API 키는 자체 백엔드에서 REST API를 호출하기 위한 것이며, MCP는 이 키를 절대 받지 않습니다. 자세한 내용은 MCP 개요와 클라이언트별 설치를 참고하세요.
오류 엔벨로프 참조
모든apx.didit.me/auth/v2 endpoint는 같은 세 가지 응답 형태를 공유합니다(openapi-auth.json 참조):
- 필드 수준 검증:
{"field": ["message", ...]}형태이며 HTTP400과 함께 반환됩니다. - 폼 수준 검증(특히 비밀번호 강도 및 인증 코드 오류): HTTP
400과 함께 단순 배열["Invalid or expired verification code."]이 반환됩니다. - 인증 / 비즈니스 규칙:
{"detail": "..."}형태이며400,401,403,404또는429와 함께 반환됩니다.429응답에는Retry-After응답 헤더가 있어 다시 시도하기 전에 얼마나 기다려야 하는지 알려줍니다(본문에는detail만 포함됩니다).
{"detail": "..."} 형식으로 반환하며, 429 응답에는 X-RateLimit-*와 Retry-After가 포함됩니다. 속도 제한을 참고하세요.