verified_claims object होता है।
यही endpoints किसी भी relying party के लिए काम करते हैं जो इस profile का पालन करता है, जिसमें Auth0 post-login Actions भी शामिल हैं।
Endpoints
हर endpoint पहचान सत्यापन ब्रिज के base URL के अंतर्गत आता है।
प्रोडक्शन और सैंडबॉक्स के लिए एक ही endpoints इस्तेमाल होते हैं।
आपके client credentials से जुड़ा एप्लिकेशन तय करता है कि कौन-सा एनवायरनमेंट इस्तेमाल होगा।
हर एनवायरनमेंट के लिए अलग client credentials और संबंधित एप्लिकेशन से जुड़ा वर्कफ़्लो इस्तेमाल करें।
सिम्युलेटेड सत्यापन परिणामों के लिए Sandbox & Test Data देखें।
{base}/.well-known/openid-configuration पर मौजूद discovery document इन सभी endpoints की जानकारी देता है:
Client authentication के लिए
client_secret_basic या client_secret_post इस्तेमाल होता है।
Authorization code flow में PKCE अनिवार्य है, जिसमें code_challenge_method=S256 होना चाहिए।
ID tokens RS256 से हस्ताक्षरित होते हैं; इन्हें JWKS endpoint से सत्यापित करें।
प्रवाह
- Relying party
POST /parपर authorization request push करती है, जिसमें PKCE challenge,state,nonce, उसका पंजीकृतredirect_uri, scopesopenid profile identity_assurance, और वे claims शामिल होते हैं जिनका सत्यापन चाहिए। Didit एक single-userequest_uriलौटाता है, जो 60 सेकंड के लिए वैध है। - Relying party उपयोगकर्ता के browser को
GET /authorize?request_uri=...पर redirect करती है। Didit एक verification सत्र बनाता है और उपयोगकर्ता को hosted verification flow में भेजता है। - जब उपयोगकर्ता प्रक्रिया पूरी कर लेता है, तब Didit verification decision का मूल्यांकन करता है, निकाली गई पहचान की तुलना push किए गए claims से करता है, और उपयोगकर्ता को relying party के
redirect_uriपर वापस भेजता है, साथ में एक वन-टाइमcodeऔर मूलstate। - Relying party
POST /tokenपर अपनेcode_verifierके साथ code का आदान-प्रदान करती है और एक signed ID token प्राप्त करती है।
क्लेम का अनुरोध
तुलना किए जाने वाले claims को PAR अनुरोध में standard OpenID Connectclaims parameter के अंदर भेजें।
given_name और family_name दोनों समर्थित हैं, और दोनों की हमेशा fuzzy तुलना होती है।
verified_claims एक array है, जो Okta के BYO IDV profile और नीचे दिए ID token response से मेल खाता है।
ID टोकन
ID token मेंverified_claims array होता है।
assurance_level केवल तभी VERIFIED होता है जब verification सत्र स्वीकृत हुआ और माँगा गया हर claim सत्यापित दस्तावेज़ से मेल खाया।
अन्यथा यह FAILED होता है।
verification_process Didit सत्र id है, ताकि आप verification को console में या sessions API के माध्यम से खोज सकें।
उपयोगकर्ता को तभी verified मानें जब
trust_framework IDV-DELEGATED हो और assurance_level VERIFIED हो।
कोई भी अन्य संयोजन बताता है कि verification सफल नहीं हुआ।Okta कॉन्फ़िगर करें
Didit से अनुरोध करें कि आपके production और sandbox एप्लिकेशनों के लिए identity verification सक्षम करे, हर एप्लिकेशन को उसके verification वर्कफ़्लो से जोड़े, और हर Okta tenant के लिए सटीक callback URL पंजीकृत करे। अकेला मौजूदा एप्लिकेशन या API कुंजी इस integration को सक्षम नहीं करता। Okta Admin Console में एक custom identity verification vendor जोड़ें और नीचे दिए मान भरें। Okta इस integration कोIDV_STANDARD type और ID_PROOFING protocol वाले identity provider के रूप में बनाता है, और फिर आप इसे Account Management Policy rule से संदर्भित करते हैं।
Production और sandbox को अलग-अलग identity verification integrations के रूप में, उनके संबंधित credentials के साथ कॉन्फ़िगर करें।
दोनों के लिए ऊपर दिए endpoints इस्तेमाल करें।
PKCE इस्तेमाल होने के बावजूद client secret आवश्यक है।
इस integration के लिए अलग से बनाई गई नामित API कुंजी एप्लिकेशन की प्राथमिक API कुंजी की जगह नहीं ले सकती।
अपना कॉलबैक URL Didit को दें, ताकि उसे आपके client पर पंजीकृत किया जा सके।
Okta इसे
{yourOktaOrgUrl}/idp/identity-verification/callback के रूप में बनाता है।
Auth0 कॉन्फ़िगर करें
Auth0 में कोई native IDV vendor slot नहीं है, इसलिए verification एक post-login Action से चलता है, जो उपयोगकर्ता को उसी flow में redirect करती है।DIDIT_IDV_BASE, DIDIT_CLIENT_ID और DIDIT_CLIENT_SECRET को Action secrets के रूप में सहेजें, और https://{yourAuth0Domain}/continue को Didit के साथ redirect URI के रूप में पंजीकृत करें।
Auth0 login जारी रखने के लिए
/authorize redirect में अपना state जोड़ता है।
Didit उस state को अपनाता है और /continue पर वापस भेजता है, जिससे Auth0 लेन-देन पूरा कर पाता है - आपको Auth0 का state PAR body में नहीं डालना होता (वह redirect तक उत्पन्न नहीं होता)।PKCE
code_verifier को हर login लेन-देन के हिसाब से सहेजें (event.transaction.id को कुंजी के रूप में इस्तेमाल करके), एक ही app_metadata फ़ील्ड में नहीं।
अगर उपयोगकर्ता पुनः प्रयास करता है या एक साथ चलने वाला लॉगिन चलाता है, तो एक साझा फ़ील्ड पर नया मान लिख दिया जाता है और token का आदान-प्रदान invalid_grant के साथ विफल हो जाता है।त्रुटियाँ
त्रुटियाँ RFC 6749 और RFC 9126 का पालन करती हैं। विफल क्लाइंट प्रमाणीकरण401 लौटाता है, जिसके साथ {"error": "invalid_client"} आता है। समय-सीमा समाप्त या दोबारा भेजे गए request_uri या प्राधिकरण कोड पर 400 लौटता है, जिसके साथ invalid_request या invalid_grant आता है।
प्राधिकरण कोड, request_uri मान और सत्यापन सत्र, इन सभी का उपयोग केवल एक बार किया जा सकता है।