पुष्टि करना और अनुमति देना

इस सेक्शन में, Fleet Engine को लागू करने के लिए, पुष्टि करने और अनुमति देने के सिद्धांतों के बारे में बताया गया है. इसमें उन प्रक्रियाओं के बारे में बताया गया है जो Fleet Engine फ़ंक्शन कॉल को सुरक्षित रखने के लिए करनी होती हैं.

आपके पास Google Cloud Console के ज़रिए, लास्ट माइल फ़्लीट सलूशन की सुविधाओं को कॉन्फ़िगर करने का विकल्प है. इन एपीआई और SDK टूल को ऐसे JSON वेब टोकन (JWT) की ज़रूरत होती है जिन्हें Cloud Console से बनाए गए सेवा खातों से साइन किया गया हो.

खास जानकारी

अनुमति देने वाले अपने तरीके के तौर पर, Fleet Engine ऐसे कॉल के लिए ज़्यादा सुरक्षा देता है जो भरोसेमंद न हों. कम भरोसेमंद माहौल में स्मार्टफ़ोन और ब्राउज़र शामिल हैं. इसके अलावा, Fleet Engine ने कम से कम अधिकारों के सिद्धांत का इस्तेमाल किया. इसके तहत, कॉल को सिर्फ़ वे खास अधिकार दिए जाने चाहिए जो काम पूरा करने के लिए ज़रूरी हैं.

लो-ट्रस्ट एनवायरमेंट से आने वाले फ़ंक्शन कॉल की सुरक्षा के लिए, Google ने एक ऐसा तरीका डिज़ाइन किया है जिसमें आपका कोड आपके बैकएंड सर्वर पर एक टोकन बनाता है. बैकएंड सर्वर पूरी तरह से भरोसेमंद एनवायरमेंट है. हर कॉल में सुरक्षा की पूरी जानकारी होती है. इसके बाद, इसे JWT में एन्क्रिप्ट (सुरक्षित) किया जाता है. इसे किसी भी एनवायरमेंट से कॉल किया जाता है.

पुष्टि करने के लिए डिज़ाइन के सिद्धांत

Fleet Engine की पुष्टि करने की प्रोसेस में, डिज़ाइन से जुड़े इन सिद्धांतों को ध्यान में रखा गया है.

  • IAM रोल से कॉलर के लिए अनुमति पा चुकी गतिविधि का दायरा तय होता है. उदाहरण के लिए, SuperUser की भूमिका को सभी काम करने की अनुमति है, जबकि SuperUser की भूमिका वाले उपयोगकर्ता को सिर्फ़ जगह की जानकारी का बहुत कम अपडेट करने की अनुमति है.

  • IAM भूमिकाएं, सेवा खातों से जुड़ी होती हैं.

  • JWT का दावा, उन इकाइयों को और सीमित कर देता है जिन पर कॉलर हो सकता है. ये चुनिंदा टास्क या डिलीवरी वाहन हो सकते हैं.

  • Fleet Engine को भेजे गए अनुरोधों में हमेशा JWT शामिल होता है.

    • JWT, सेवा खातों से जुड़ा होता है, इसलिए Fleet Engine को भेजे गए अनुरोध, साफ़ तौर पर JWT से जुड़े सेवा खाते से जुड़े होते हैं.

  • Fleet Engine को भेजने के लिए, सही JWT का अनुरोध करने के लिए, सबसे पहले पूरी तरह भरोसेमंद एनवायरमेंट में चल रहे आपके कोड को कॉल करना ज़रूरी है.

  • Fleet Engine, सुरक्षा से जुड़ी ये जांच करता है:

    1. सेवा खाते से जुड़ी IAM रोल, एपीआई कॉल जारी करने के लिए कॉलर को सही अनुमति देती हैं.

    2. अनुरोध में पास किए गए JWT दावे, कॉलर को इकाई पर ऑपरेट करने की सही अनुमति देते हैं.

पुष्टि करने का फ़्लो

नीचे दिए गए क्रम के डायग्राम में, पुष्टि करने की प्रोसेस की जानकारी दिखाई गई है.

  1. फ़्लीट एडमिन, सेवा खाते बनाता है.

  2. फ़्लीट एडमिन, सेवा खातों के लिए खास IAM भूमिकाएं असाइन करता है.

  3. फ़्लीट का एडमिन, सेवा खातों के साथ अपने बैकएंड को कॉन्फ़िगर करता है.

  4. क्लाइंट ऐप्लिकेशन, पार्टनर के बैकएंड से JWT का अनुरोध करता है. अनुरोध करने वाला ड्राइवर ऐप्लिकेशन, उपभोक्ता ऐप्लिकेशन या निगरानी करने वाला ऐप्लिकेशन हो सकता है.

  5. Fleet Engine, संबंधित सेवा खाते के लिए JWT जारी करता है. क्लाइंट ऐप्लिकेशन को JWT मिलता है.

  6. क्लाइंट ऐप्लिकेशन, डेटा पढ़ने या उसमें बदलाव करने के लिए, Fleet Engine से कनेक्ट करने के लिए JWT का इस्तेमाल करता है. यह ऐप्लिकेशन, सेट अप के दौरान असाइन की गई IAM रोल पर निर्भर करता है.

पुष्टि करने के क्रम का डायग्राम

Cloud प्रोजेक्ट का सेटअप

अपना क्लाउड प्रोजेक्ट सेट अप करने के लिए, पहले अपना प्रोजेक्ट बनाएं. इसके बाद, सेवा खाते बनाएं.

Google Cloud प्रोजेक्ट बनाने के लिए:

  1. Google Cloud Console का इस्तेमाल करके, Google Cloud प्रोजेक्ट बनाएं.
  2. एपीआई और सेवा डैशबोर्ड का इस्तेमाल करके, Local Rides and डिलीवरी API को चालू करें.

सेवा खाते और IAM रोल

सेवा खाता एक खास तरह का खाता होता है, जिसका इस्तेमाल कोई व्यक्ति करने के बजाय कोई ऐप्लिकेशन करता है. आम तौर पर, सेवा खाते का इस्तेमाल JWT को मिंट करने के लिए किया जाता है, जो भूमिका के आधार पर अनुमतियों के अलग-अलग सेट देते हैं. गलत इस्तेमाल की संभावना को कम करने के लिए, कई सेवा खाते बनाए जा सकते हैं. हर खाते में, कम से कम ज़रूरी भूमिकाएं होनी चाहिए.

लास्ट माइल फ़्लीट सलूशन इन भूमिकाओं का इस्तेमाल करता है:

भूमिकाब्यौरा
फ़्लीट इंजन डिलीवरी करने वाले भरोसेमंद ड्राइवर का उपयोगकर्ता

roles/fleetengine.deliveryTrustedDriver		 डिलीवरी वाहन और टास्क बनाने और अपडेट करने की अनुमति देता है. इसमें डिलीवरी वाहन की जगह और टास्क का स्टेटस या नतीजा अपडेट करना भी शामिल है. इस भूमिका वाले सेवा खाते से बनाए गए टोकन आम तौर पर, डिलीवरी ड्राइवर के मोबाइल डिवाइसों या आपके बैकएंड सर्वर से इस्तेमाल किए जाते हैं.
फ़्लीट इंजन डिलीवरी करने वाला गैर-भरोसेमंद ड्राइवर उपयोगकर्ता

roles/fleetengine.deliveryUntrustedDriver		 डिलीवरी वाहन की जगह की जानकारी अपडेट करने की अनुमति देता है. इस भूमिका वाले सेवा खाते से बनाए गए टोकन, आम तौर पर आपके डिलीवरी ड्राइवर के मोबाइल डिवाइसों से इस्तेमाल किए जाते हैं.
फ़्लीट इंजन डिलीवरी उपभोक्ता उपयोगकर्ता

roles/fleetengine.deliveryConsumer		 ट्रैकिंग आईडी का इस्तेमाल करके टास्क खोजने और टास्क की जानकारी पढ़ने की अनुमति देता है, लेकिन उसे अपडेट नहीं करता. इस भूमिका वाले सेवा खाते से बनाए गए टोकन, आम तौर पर डिलीवरी उपभोक्ता के वेब ब्राउज़र से इस्तेमाल किए जाते हैं.
फ़्लीट इंजन डिलीवरी सुपर यूज़र

roles/fleetengine.deliverySuperUser		 सभी डिलीवरी वाहनों और टास्क के एपीआई को अनुमति देता है. इस भूमिका वाले सेवा खाते से बनाए गए टोकन, आम तौर पर आपके बैकएंड सर्वर से इस्तेमाल किए जाते हैं.
फ़्लीट इंजन डिलीवरी फ़्लीट रीडर

roles/fleetengine.deliveryFleetReader		 डिलीवरी वाहनों और टास्क को पढ़ने के साथ-साथ ट्रैकिंग आईडी का इस्तेमाल करके टास्क खोजने की अनुमति देता है. इस भूमिका वाले सेवा खाते से बनाए गए टोकन, आम तौर पर डिलीवरी फ़्लीट ऑपरेटर के वेब ब्राउज़र से इस्तेमाल किए जाते हैं.

जो संगठन अपने डिलीवरी ड्राइवर को कॉर्पोरेट आईटी से मैनेज किए जाने वाले डिवाइस देते हैं वे फ़्लीट इंजन भरोसेमंद ड्राइवर उपयोगकर्ता की भूमिका से मिलने वाली सुविधाओं का फ़ायदा ले सकते हैं. साथ ही, वे मोबाइल ऐप्लिकेशन में कुछ या सभी फ़्लीट इंजन इंटरैक्शन को इंटिग्रेट कर सकते हैं.

Bring My Device से जुड़ी नीतियों के साथ काम करने वाले संगठनों को, फ़्लीट इंजन की गैर-भरोसेमंद ड्राइवर उपयोगकर्ता भूमिका की सुरक्षा के लिए ऑप्ट-इन करना चाहिए. साथ ही, Fleet Engine को वाहन की जगह की जानकारी से जुड़े अपडेट भेजने के लिए, सिर्फ़ मोबाइल ऐप्लिकेशन पर भरोसा करना चाहिए. अन्य सभी इंटरैक्शन, ग्राहक बैकएंड सर्वर से होने चाहिए.

ड्राइवर और उपभोक्ता के SDK टूल, इन स्टैंडर्ड भूमिकाओं के हिसाब से बनाए जाते हैं. हालांकि, कस्टम रोल बनाए जा सकते हैं, जो अनुमतियों के मनमुताबिक सेट को एक साथ बंडल करने की अनुमति देते हैं. ज़रूरी अनुमति उपलब्ध न होने पर, ड्राइवर और उपभोक्ता SDK टूल गड़बड़ी के मैसेज दिखाएंगे. इसलिए, हम सुझाव देते हैं कि आप कस्टम भूमिकाओं के बजाय, ऊपर बताई गई भूमिकाओं के स्टैंडर्ड सेट का इस्तेमाल करें.

सेवा खाता बनाना

Google Cloud Console में IAM & Admin > Service Accounts टैब का इस्तेमाल करके, सेवा खाता बनाया जा सकता है. भूमिका ड्रॉप-डाउन सूची से, फ़्लीट इंजन चुनें और सेवा खाते को कोई एक भूमिका असाइन करें. हर भूमिका से जुड़े खाते के बारे में बताना अच्छा तरीका है. उदाहरण के लिए, सेवा खाते को ऐसा नाम दें जो समझ में आए.

सुविधा के लिए, अगर आपको गैर-भरोसेमंद क्लाइंट के लिए JWTs मिंट करने की ज़रूरत है, तो सेवा खाता टोकन क्रिएटर भूमिका में उपयोगकर्ताओं को जोड़ने से, वे gcloud कमांड लाइन टूल की मदद से टोकन मिंट कर सकते हैं.

gcloud projects add-iam-policy-binding project-id \
       --member=user:my-user@example.com \
       --role=roles/iam.serviceAccountTokenCreator

जहां my-user@example.com ईमेल पता है, जिसका इस्तेमाल gcloud (gcloud auth list --format='value(account)') से पुष्टि करने के लिए किया जाता है.

फ़्लीट इंजन ऑथराइज़ेशन लाइब्रेरी

Fleet Engine API के ऐक्सेस को सीमित करने के लिए, Fleet Engine JWT का इस्तेमाल करता है. नई Fleet Engine Auth Library, GitHub पर उपलब्ध है. इससे, Fleet Engine JWT बनाने और उन्हें सुरक्षित तरीके से साइन करने में मदद मिलती है.

इस लाइब्रेरी से ये फ़ायदे मिलते हैं:

  • फ़्लीट इंजन टोकन बनाने की प्रोसेस को आसान बनाता है.
  • क्रेडेंशियल फ़ाइलों का इस्तेमाल करने के अलावा, टोकन पर हस्ताक्षर करने के दूसरे तरीके उपलब्ध कराता है (जैसे, किसी सेवा खाते के नाम पर काम करना.)
  • gRPC स्टब या GAPIC क्लाइंट से किए गए आउटबाउंड अनुरोधों के साथ, साइन किए गए टोकन अटैच करता है.

अनुमति देने के लिए JSON वेब टोकन (JWT) बनाया जा रहा है

फ़्लीट इंजन ऑथराइज़ेशन लाइब्रेरी का इस्तेमाल न करने पर, JWT को सीधे आपके कोड बेस में तैयार किया जाना चाहिए. इसके लिए, आपको JWT के बारे में अच्छी तरह समझना होगा. साथ ही, आपको यह भी समझना होगा कि ये Fleet Engine से कैसे जुड़े हैं. इसलिए, हम Fleet Engine ऑथराइज़ेशन लाइब्रेरी का इस्तेमाल करने का सुझाव देते हैं.

Fleet Engine में, JWTs कुछ समय तक पुष्टि की सुविधा देता है. साथ ही, यह पक्का करता है कि डिवाइस सिर्फ़ ऐसे वाहनों या टास्क में बदलाव कर सकें जिनके लिए उन्हें अनुमति मिली हुई है. JWT में एक हेडर और एक दावा सेक्शन होता है. हेडर सेक्शन में जानकारी शामिल होती है. जैसे, इस्तेमाल करने के लिए निजी पासकोड (सेवा खातों से मिलने वाली निजी कुंजी) और एन्क्रिप्ट (सुरक्षित) करने का एल्गोरिदम. दावे वाले सेक्शन में, टोकन बनाने का समय, टोकन के बनाए जाने का समय, टोकन की ओर से ऐक्सेस का दावा करने वाली सेवाओं, और ऐक्सेस को कम करने के लिए अनुमति से जुड़ी अन्य जानकारी शामिल होती है. उदाहरण के लिए, डिलीवरी वाहन का आईडी.

JWT हेडर सेक्शन में ये फ़ील्ड होते हैं:

फ़ील्डब्यौरा
alg इस्तेमाल किया जाने वाला एल्गोरिदम. `RS256`.
typ टोकन किस तरह का है. `JWT`.
बच्चा आपके सेवा खाते का निजी कुंजी आईडी. यह वैल्यू, आपके सेवा खाते की JSON फ़ाइल के `private_key_id` फ़ील्ड में देखी जा सकती है. पक्का करें कि उस सेवा खाते की कुंजी का इस्तेमाल किया जा रहा हो जिसके पास सही लेवल की अनुमतियां हैं.

JWT के दावे वाले सेक्शन में ये फ़ील्ड होते हैं:

फ़ील्डब्यौरा
है आपके सेवा खाते का ईमेल पता.
बदले में खेलने वाला खिलाड़ी आपके सेवा खाते का ईमेल पता.
ऑड आपके सेवा खाते का Service_NAME, इस मामले में https://fleetengine.googleapis.com/
Iat टोकन बनाए जाने के समय का टाइमस्टैंप, जिसे 1 जनवरी, 1970 को 00:00:00 यूटीसी के बाद, बीत चुके सेकंड में बताया गया है. स्क्यू के लिए 10 मिनट दें. अगर टाइमस्टैंप बहुत पहले का या आने वाले समय का है, तो सर्वर कोई गड़बड़ी रिपोर्ट कर सकता है.
exp टोकन की समयसीमा खत्म होने के बाद का टाइमस्टैंप, जिसे 1 जनवरी, 1970 को 00:00:00 यूटीसी के बाद, बीत चुके सेकंड में बताया गया है. अगर टाइमस्टैंप के लिए, आने वाले समय के एक घंटे से ज़्यादा का समय है, तो अनुरोध पूरा नहीं किया जा सकता.
अनुमति देना इस्तेमाल के उदाहरण के हिसाब से, इसमें `deliveryvehicleid`, `trackingid`, `taskid` या `taskids` हैं.

JWT टोकन मिंट करने का मतलब है कि उस पर हस्ताक्षर करना. JWT बनाने और साइन करने के निर्देश और कोड सैंपल के लिए, OAuth के बिना सेवा खाते की अनुमति देना देखें. इसके बाद, gRPC कॉल में मिंट किया गया टोकन अटैच किया जा सकता है. इसके अलावा, Fleet Engine को ऐक्सेस करने के लिए इस्तेमाल किए जाने वाले अन्य तरीकों से भी ऐसा किया जा सकता है.

JWT दावे

लास्ट माइल फ़्लीट सलूशन, निजी दावों का इस्तेमाल करता है. निजी दावों का इस्तेमाल करने से यह पक्का होता है कि सिर्फ़ वे क्लाइंट ही अपना डेटा ऐक्सेस कर सकते हैं जिनको इसकी अनुमति है. उदाहरण के लिए, जब आपका बैकएंड, डिलीवरी ड्राइवर के मोबाइल डिवाइस के लिए JSON वेब टोकन जारी करता है, तो उस टोकन में deliveryvehicleid दावा होना चाहिए. साथ ही, उस टोकन में ड्राइवर के डिलीवरी वाले वाहन के आईडी की वैल्यू शामिल होनी चाहिए. इसके बाद, ड्राइवर की भूमिका के आधार पर, टोकन से सिर्फ़ खास तौर पर डिलीवर किए जाने वाले वाहन के आईडी को ऐक्सेस किया जा सकता है, किसी अन्य आर्बिट्रेरी वाहन आईडी को नहीं.

लास्ट माइल फ़्लीट सलूशन, इन निजी दावों का इस्तेमाल करता है:

  • deliveryvehicleid - हर डिलीवरी-वाहन एपीआई को कॉल करते समय इस्तेमाल करें.
  • taskid - हर टास्क वाले एपीआई को कॉल करते समय इस्तेमाल करें.
  • taskids - BatchCreateTasksAPI को कॉल करते समय इस्तेमाल करें. यह दावा, अरे के तौर पर होना चाहिए. साथ ही, कलेक्शन में अनुरोध पूरा करने के लिए सभी ज़रूरी टास्क आईडी होने चाहिए. delivervehicleid, trackingid या taskid दावे शामिल न करें.
  • trackingid - इसका इस्तेमाल, SearchTasksAPI पर कॉल करते समय करें. दावा, अनुरोध में मौजूद ट्रैकिंग आईडी से मेल खाना चाहिए. delivervehicleid, taskid या taskids दावे शामिल न करें.

अपने बैकएंड सर्वर से एपीआई को कॉल करते समय, टोकन में सही दावा होना चाहिए. हालांकि, deliveryvehicleid, taskid, और trackingid दावों के लिए, स्टार के निशान ("*") की खास वैल्यू का इस्तेमाल किया जा सकता है. taskids दावे में भी तारे के निशान ("*") का इस्तेमाल किया जा सकता है, लेकिन अरे में यही एलिमेंट होना चाहिए.

अगर आपको OAuth 2.0 ऐक्सेस टोकन के बजाय, सीधे टोकन बियरर के तौर पर JSON बनाना है और उस पर हस्ताक्षर करना है, तो Identity डेवलपर के दस्तावेज़ में, OAuth के बिना सेवा खाते की अनुमति देना के लिए दिए गए निर्देश पढ़ें.

किसी gRPC कॉल में टोकन को अटैच करने का तरीका, कॉल करने के लिए इस्तेमाल की गई भाषा और फ़्रेमवर्क पर निर्भर करता है. किसी एचटीटीपी कॉल में टोकन तय करने की प्रोसेस में, एक बियरर टोकन के साथ ऑथराइज़ेशन हेडर शामिल करना होता है. इस टोकन की वैल्यू टोकन होती है. यह जानकारी, अलग-अलग शिपमेंट ट्रैकिंग या फ़्लीट परफ़ॉर्मेंस के इस्तेमाल के उदाहरणों के लिए, अनुमति वाले नोट में दी गई है.

नीचे दिया गया उदाहरण आपके बैकएंड सर्वर से, हर टास्क के लिए एक टोकन दिखाता है:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "taskid": "*"
       }
    }

नीचे दिया गया उदाहरण आपके बैकएंड सर्वर से, टास्क बनाने की कार्रवाई के बैच के लिए टोकन दिखाता है:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "taskids": ["*"]
       }
    }

इस उदाहरण में, आपके बैकएंड सर्वर से हर वाहन की डिलीवरी के लिए टोकन दिखाया गया है:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_provider_service_account"
    }
    .
    {
      "iss": "provider@yourgcpproject.iam.gserviceaccount.com",
      "sub": "provider@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "deliveryvehicleid": "*"
       }
    }

यहां दिए गए उदाहरण में, असली उपयोगकर्ता के ग्राहकों के लिए टोकन दिखाया गया है:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_delivery_consumer_service_account"
    }
    .
    {
      "iss": "consumer@yourgcpproject.iam.gserviceaccount.com",
      "sub": "consumer@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "trackingid": "shipment_12345"
       }
    }

नीचे दिया गया उदाहरण आपके ड्राइवर ऐप्लिकेशन के लिए टोकन दिखाता है:

    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "private_key_id_of_delivery_driver_service_account"
    }
    .
    {
      "iss": "driver@yourgcpproject.iam.gserviceaccount.com",
      "sub": "driver@yourgcpproject.iam.gserviceaccount.com",
      "aud": "https://fleetengine.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600,
      "authorization": {
         "deliveryvehicleid": "driver_12345"
       }
    }
  • हेडर में मौजूद kid फ़ील्ड के लिए, अपने सेवा खाते का निजी कुंजी आईडी तय करें. आपको यह वैल्यू अपने सेवा खाते की JSON फ़ाइल के private_key_id फ़ील्ड में दिखेगी.
  • iss और sub फ़ील्ड के लिए, अपने सेवा खाते का ईमेल पता बताएं. आपको यह वैल्यू अपने सेवा खाते की JSON फ़ाइल के client_email फ़ील्ड में दिखेगी.
  • aud फ़ील्ड के लिए, https://SERVICE_NAME/ बताएं.
  • iat फ़ील्ड के लिए, टोकन बनाए जाने के समय का टाइमस्टैंप बताएं. यह टाइमस्टैंप 1 जनवरी, 1970 को 00:00:00 यूटीसी के बाद 00:00:00 सेकंड के बाद का है. स्क्वी के लिए 10 मिनट दें. अगर टाइमस्टैंप बहुत पहले का या आने वाले समय का है, तो सर्वर कोई गड़बड़ी रिपोर्ट कर सकता है.
  • exp फ़ील्ड के लिए, 1 जनवरी, 1970 को 00:00:00 यूटीसी से 00:00:00 यूटीसी के बाद, टोकन की समयसीमा खत्म होने के टाइमस्टैंप की जानकारी दें. सुझाई गई वैल्यू iat + 3600 है.

किसी मोबाइल डिवाइस या असली उपयोगकर्ता को भेजे जाने वाले टोकन पर हस्ताक्षर करते समय, पक्का करें कि डिलीवरी ड्राइवर या उपभोक्ता की भूमिका के लिए क्रेडेंशियल फ़ाइल का इस्तेमाल किया गया हो. ऐसा न होने पर, मोबाइल डिवाइस या असली उपयोगकर्ता उस जानकारी में बदलाव कर सकते हैं या देख पाएंगे जिसका ऐक्सेस उनके पास नहीं होना चाहिए.