रिफ्रेश टोकन

एक्सेस टोकन जानबूझकर अल्पकालिक होते हैं, इसलिए चोरी हुआ टोकन भी थोड़े समय के लिए ही उपयोगी होता है। रिफ्रेश टोकन इसका विपरीत होता है और इसकी वैधता अवधि लंबी होती है: क्लाइंट इसे अपने पास रखता है, इसे कभी भी संसाधन सर्वरों को नहीं भेजता, और जब उसे नए एक्सेस टोकन की आवश्यकता होती है तो इसे केवल प्राधिकरण सर्वर को ही प्रस्तुत करता है।

यह काम किस प्रकार करता है

जब कोई API एक्सेस टोकन की समय सीमा समाप्त होने (या समाप्त होने से ठीक पहले) के कारण 401 प्रतिक्रिया देता है, तो क्लाइंट टोकन एंडपॉइंट पर grant_type=refresh_token लिखकर POST रिक्वेस्ट भेजता है और एक नया एक्सेस टोकन प्राप्त करता है, जिसमें अक्सर एक नया रिफ्रेश टोकन भी शामिल होता है जो पुराने टोकन की जगह ले लेता है (रोटेशन)। रोटेट किए गए रिफ्रेश टोकन का पुनः उपयोग चोरी का संकेत है, और अच्छी तरह से डिज़ाइन किए गए सर्वर तब पूरी श्रृंखला को रद्द कर देते हैं।

गलत धारणा

हर 401 त्रुटि पर रिफ्रेश करना सही है। निरस्त या अमान्य टोकन के कारण आने वाली 401 त्रुटि रिफ्रेश करने के बाद भी दोबारा विफल हो जाएगी; जो क्लाइंट बार-बार रिफ्रेश और रिट्राई करता है, वह लॉगआउट को एक अनंत लूप में बदल देता है। एक बार रिफ्रेश करें, एक बार रिट्राई करें और यदि वह विफल हो जाए तो उपयोगकर्ता को लॉग इन करने के लिए भेजें।

इसे यहाँ आजमाएँ

POST /auth/v1/oauth/token ऑथराइजेशन कोड फ्लो में एक रिफ्रेश टोकन जारी करता है और नया एक्सेस टोकन प्राप्त करने के लिए grantType refresh_token को उस रिफ्रेश टोकन के साथ स्वीकार करता है। यहां एक्सेस टोकन 15 सेकंड के बाद समाप्त हो जाते हैं, इसलिए रिफ्रेश प्रक्रिया जल्दी पूरी हो जाती है।

स्रोत

अन्य शब्द

यह पृष्ठ अंग्रेज़ी में पढ़ें

सभी शब्द · परीक्षण तकनीकें · सभी 39 मॉक REST API

आखरी अपडेट