RESTful API में टोकन नवीनीकरण / सत्र समाप्ति को संभालना

Question

मैं एक RESTful API का निर्माण कर रहा हूं जो उपयोगकर्ता प्रमाणीकरण के लिए JWT टोकन का उपयोग करता है (एक loginसमापन बिंदु द्वारा जारी किया गया है और बाद में सभी हेडर में भेजा गया है), और टोकन को एक निश्चित समय के बाद ताज़ा किया जाना चाहिए (एक renewसमापन बिंदु, जो एक नवीनीकृत टोकन लौटाता है )।

यह संभव है कि टोकन समाप्त होने से पहले उपयोगकर्ता का एपीआई सत्र अमान्य हो जाता है, इसलिए मेरे सभी समापन बिंदु यह जांचने से शुरू होते हैं कि: 1) टोकन अभी भी वैध है और 2) उपयोगकर्ता का सत्र अभी भी वैध है। टोकन को सीधे अमान्य करने का कोई तरीका नहीं है, क्योंकि ग्राहक इसे स्थानीय रूप से संग्रहीत करते हैं।

इसलिए मेरे सभी समापन बिंदुओं को दो संभावित परिस्थितियों के अपने ग्राहकों को संकेत देना है: 1) यह टोकन या 2 को नवीनीकृत करने का समय है) कि सत्र अमान्य हो गया है, और उन्हें अब सिस्टम तक पहुंचने की अनुमति नहीं है। मैं अपने समापन बिंदु के लिए अपने ग्राहकों को संकेत देने के लिए दो विकल्पों के बारे में सोच सकता हूं, जब दो स्थितियों में से एक होता है (मान लें कि ग्राहकों को या तो विकल्प के रूप में अनुकूलित किया जा सकता है):

1. एक HTTP 401 कोड (अनधिकृत) लौटाएं यदि सत्र अमान्य हो गया है या टोकन समाप्त हो जाने पर 412 कोड (पूर्ववर्ती विफल) वापस कर दिया है और यह renewसमापन बिंदु कॉल करने का समय है , जो 200 (ओके) कोड लौटाएगा।
2. 401 को यह संकेत देने के लिए लौटें कि या तो सत्र अमान्य है या टोकन समाप्त हो गया है। इस स्थिति में क्लाइंट तुरंत renewसमापन बिंदु को कॉल करेगा , यदि यह 200 पर लौटाता है तो टोकन रीफ्रेश हो जाता है, लेकिन अगर renewयह 401 भी वापस आता है तो इसका मतलब है कि क्लाइंट सिस्टम से बाहर है।

आप इन दोनों विकल्पों में से कौन सा विकल्प सुझाएंगे? कौन सा अधिक मानक होगा, समझने में सरल होगा, और / या अधिक प्रतिष्ठित? या आप पूरी तरह से एक अलग दृष्टिकोण की सिफारिश करेंगे? क्या आपको किसी भी विकल्प के साथ कोई स्पष्ट समस्या या सुरक्षा जोखिम दिखाई देता है? यदि आपके उत्तर में बाहरी संदर्भ शामिल हैं जो आपकी राय का समर्थन करते हैं तो अतिरिक्त बिंदु।

अपडेट करें

दोस्तों, कृपया वास्तविक प्रश्न पर ध्यान दें - नवीनीकरण / सत्र अमान्य को संकेत देने के लिए दो http कोड विकल्पों में से कौन सा सबसे अच्छा है? इस तथ्य पर ध्यान न दें कि मेरा सिस्टम JWT और सर्वर-साइड सत्रों का उपयोग करता है , यह बहुत विशिष्ट व्यावसायिक नियमों के लिए मेरे एपीआई की ख़ासियत है, और उस भाग के लिए नहीं जिसकी मैं मदद मांग रहा हूं;)

Comments

टोकन समाप्त होने से पहले उपयोगकर्ता का सत्र कैसे अमान्य हो जाएगा, एक छोटा (लगभग 5 मिनट) समाप्ति समय मानकर?

— जैक

व्यापार नियम के कारण, सिस्टम का एक अलग हिस्सा सत्र को अमान्य कर सकता है।

— लोपेज

JWTs पहचान के प्रमाण के लिए हैं, जैसा कि "यह अनुरोध उपयोगकर्ता X से साबित होता है"। यदि आपका व्यावसायिक नियम कुछ ऐसा है जैसे "उपयोगकर्ता X को अब संसाधन Y के साथ सहभागिता करने की अनुमति नहीं है", तो यह कुछ ऐसा है जिसे JWT से अलग से जाँचना चाहिए।

— जैक

@ ठीक है! यह मेरी बात ठीक है, और यही कारण है कि मुझे सत्र की जानकारी बचाने के लिए एक अतिरिक्त, राज्य परत का उपयोग करना पड़ता है। सादा JWT, जैसा कि हो सकता है, अच्छा है, बस काम के लिए कटौती नहीं की जाती है।

— लोपेज

आपको मेरे उत्तर में दिलचस्पी हो सकती है :)

— जैक

Answer 1

यह प्रमाणीकरण बनाम प्राधिकरण के एक मामले की तरह लगता है ।

JWTs एक अनुरोध के प्रवर्तक के बारे में क्रिप्टोग्राफिक रूप से हस्ताक्षरित दावे हैं। JWT में "यह अनुरोध उपयोगकर्ता X के लिए है" और "उपयोगकर्ता X की व्यवस्थापक भूमिकाएँ हैं" जैसे दावे हो सकते हैं। पासवर्ड, हस्ताक्षर और टीएलएस के माध्यम से इस प्रमाण को प्राप्त करना और प्रदान करना प्रमाणीकरण का क्षेत्र है - यह साबित करना कि आप जो कहते हैं वही आप हैं।

उन दावों का आपके सर्वर के लिए क्या मतलब है - विशिष्ट उपयोगकर्ताओं और भूमिकाओं को क्या करने की अनुमति है - प्राधिकरण की समस्या है । दोनों के बीच के अंतर को दो परिदृश्यों के साथ वर्णित किया जा सकता है। मान लीजिए कि बॉब अपनी कंपनी के गोदाम के प्रतिबंधित भंडारण खंड में प्रवेश करना चाहता है, लेकिन पहले उसे जिम नामक एक गार्ड के साथ व्यवहार करना होगा।

परिदृश्य A - प्रमाणीकरण

• बॉब: "हैलो जिम, मैं प्रतिबंधित भंडारण दर्ज करना चाहूंगा।"
• जिम: "क्या आपको अपना बिल्ला मिला है?"
• बॉब: "नहीं, भूल गए।"
• जिम: "सॉरी पाल, बैज के बिना नो एंट्री।"

परिदृश्य बी - प्राधिकरण

• बॉब: "हैलो जिम, मैं प्रतिबंधित भंडारण दर्ज करना चाहूंगा। यहाँ मेरा बिल्ला है।"
• जिम: "अरे बॉब, आपको यहां प्रवेश करने के लिए स्तर 2 की मंजूरी चाहिए। क्षमा करें।"

JWT समाप्ति समय एक प्रमाणीकरण उपकरण है जिसका उपयोग दूसरों को चोरी करने से रोकने के लिए किया जाता है। यदि आपके सभी JWT में पांच मिनट की समय सीमा समाप्त हो जाती है, तो चोरी होने पर यह लगभग उतना बड़ा नहीं होता क्योंकि वे जल्दी बेकार हो जाते हैं। हालाँकि, "सत्र समाप्ति" नियम आप चर्चा करते हैं एक प्राधिकरण समस्या की तरह लगता है। राज्य में कुछ बदलाव का मतलब है कि उपयोगकर्ता एक्स को अब कुछ करने की अनुमति नहीं है जो वे करने में सक्षम थे। उदाहरण के लिए, उपयोगकर्ता बॉब को निकाल दिया गया हो सकता है - इससे कोई फर्क नहीं पड़ता कि उसका बिल्ला कहता है कि वह बॉब है, क्योंकि बस बॉब होने के नाते अब उसे कंपनी के साथ कोई अधिकार नहीं दिया जाता है।

इन दो मामलों में अलग-अलग HTTP प्रतिक्रिया कोड हैं: 401 Unauthorizedऔर 403 Forbidden। दुर्भाग्यवश 401 कोड नाम प्रमाणीकरण मुद्दों जैसे गुमशुदा, समाप्त या निरस्त क्रेडेंशियल के लिए है। 403 प्राधिकरण के लिए है, जहां सर्वर को ठीक-ठीक पता है कि आप कौन हैं, लेकिन आपको वह काम करने की अनुमति नहीं है जिसे आप करने का प्रयास कर रहे हैं। उपयोगकर्ता के खाते को हटाए जाने की स्थिति में, एक JWT के साथ एक समापन बिंदु पर कुछ करने का प्रयास करने के परिणामस्वरूप 403 निषिद्ध प्रतिक्रिया होगी। हालांकि, अगर JWT की समय सीमा समाप्त हो जाती है, तो सही परिणाम 401 अनधिकृत होगा।

एक सामान्य JWT पैटर्न "लंबे समय तक जीवित" और "अल्पकालिक" टोकन है। लंबे समय तक जीवित रहने वाले टोकन को ग्राहक पर संग्रहीत किया जाता है जैसे कि लघु जीवित टोकन, लेकिन वे दायरे में सीमित होते हैं और केवल आपके प्राधिकरण प्रणाली के साथ कम जीवित टोकन प्राप्त करने के लिए उपयोग किए जाते हैं। लंबे समय तक रहने वाले टोकन, जैसा कि नाम से पता चलता है, बहुत लंबे समय तक समाप्ति अवधि है - आप अंत में दिनों या हफ्तों के लिए नए टोकन का अनुरोध करने के लिए उनका उपयोग कर सकते हैं। लघु जीवित टोकन आपके द्वारा बताए गए टोकन हैं, जिन्हें आपके सिस्टम के साथ बातचीत करने के लिए बहुत कम समय समाप्ति के साथ उपयोग किया जाता है। याद रखें कार्यक्षमता को लागू करने के लिए लंबे समय तक टोकन उपयोगी होते हैं, इसलिए आपको नया शॉर्ट लाइव टोकन प्राप्त करने के लिए हर पांच मिनट में अपने पासवर्ड की आपूर्ति करने की आवश्यकता नहीं है।

"सत्र अमान्यकरण" समस्या जिसे आप लंबे समय तक जीवित JWT को अमान्य करने के प्रयास के समान ध्वनियों का वर्णन कर रहे हैं, क्योंकि अल्पकालिक लोग शायद ही कभी सर्वर-साइड संग्रहीत होते हैं जबकि लंबे समय तक रहने वाले लोगों को ट्रैक किया जाता है, जब उन्हें निरस्त किए जाने की आवश्यकता होती है। ऐसी प्रणाली में, एक लंबे समय तक रहने वाले टोकन के साथ क्रेडेंशियल्स प्राप्त करने का प्रयास करने के परिणामस्वरूप 401 अनधिकृत परिणाम प्राप्त होंगे, क्योंकि उपयोगकर्ता तकनीकी रूप से क्रेडेंशियल प्राप्त करने में सक्षम हो सकते हैं, लेकिन वे जिस टोकन का उपयोग कर रहे हैं वह कार्य के लिए उपयुक्त नहीं है। तब जब उपयोगकर्ता अपने उपयोगकर्ता नाम और पासवर्ड का उपयोग करके एक नया लंबे समय तक टोकन प्राप्त करने का प्रयास करता है, तो सिस्टम 403 निषिद्ध के साथ जवाब दे सकता है यदि वे सिस्टम से बाहर निकाल दिए जाते हैं।

Comments

यह वह मार्गदर्शन है जिसकी मैं तलाश कर रहा था, और आप चर्चा के लिए एक बहुत ही प्रासंगिक अंतर्दृष्टि लाए - कि यह प्रमाणीकरण बनाम प्राधिकरण का मामला है, और प्रत्येक को अलग तरीके से निपटा जाना चाहिए। धन्यवाद!

— Oscar Lopez

Answer 2

आपका एपीआई सत्र एक ऐसी चीज है, जो किसी प्रतिष्ठित दुनिया में बिल्कुल भी मौजूद नहीं होनी चाहिए। रेस्टफुल ऑपरेशंस को स्टेटलेस माना जाता है, सेशन में स्टेट्स होते हैं और इस तरह रैस्टफुल दुनिया में कोई जगह नहीं है।

JWT यह निर्धारित करने के लिए आपका एकमात्र तरीका होना चाहिए कि उपयोगकर्ता अभी भी समापन बिंदु तक पहुँचने के योग्य है या नहीं। एक सत्र में इसमें कोई भूमिका नहीं होनी चाहिए। यदि ऐसा होता है, तो आपके पास RESTful API नहीं है।

जब आप सत्र को पूरी तरह से समाप्त कर देते हैं, जो कि यदि आप एक RESTful API के लिए लक्ष्य कर रहे हैं जो आपको करना चाहिए, और केवल JWT को एक प्रामाणिक कारक के रूप में उपयोग करें, तो एक उपयोगकर्ता आपके समापन बिंदु का उपयोग करने के लिए अधिकृत है या नहीं - जिस स्थिति में 401 Unauthorizedप्रतिक्रिया कोड उपयुक्त है - और आपके द्वारा उपयोग किए जा रहे नवीकरण की पहचान के renewसाथ समापन बिंदु को कॉल करना चाहिए grant_type=refresh_token।

अपडेट करें:

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

  Client        RESTful API      JWT Issuer
     |              |                |
     |----- 1. ---->|                | 
     |              |------ 2. ----->|-----
     |              |                | 3. |
     |              |<----- 4. ------|<----
-----|<---- 5. -----|                |
| 6. |              |                |
---->|----- 7. ---->|                |
     |              |------ 8. ----->|-----
     |              |                | 9. |
     |              |<----- 10. -----|<----
     |              |                |
     |              |------          |
     |              | 11. |          |
     |<---- 12. ----|<-----          |
     |              |                |
     .              .                .

1. Ask RESTful API for a JWT using login endpoint.
2. Ask Issuer to create a new JWT.
3. Create JWT.
4. Return JWT to the RESTful API.
5. Return JWT to Client.
6. Store JWT to append it to all future API requests.
7. Ask for data from API providing JWT as authorization.
8. Send JWT to Issuer for verification.
9. Issuer verifies JWT.
10. Issuer returns 200 OK, verification successful.
11. Retrieve and format data for Client.
12. Return data to Client.

सर्वर RESTful APIको उस टोकन की वैधता की जांच करनी है जिसे प्राधिकरण के रूप में भेजा जा रहा है। की जिम्मेदारी नहीं है Client। ऐसा लगता है जैसे आप वर्तमान में ऐसा नहीं कर रहे हैं। इस तरह जेडब्ल्यूटी के सत्यापन को लागू करें और आपको सत्रों की आवश्यकता नहीं है।

Comments

आपके उत्तर के लिए धन्यवाद। सहमत होना, सत्र का उपयोग करना 100% रेस्टफुल दृष्टिकोण नहीं होगा, लेकिन जैसा कि मैंने ऊपर उल्लेख किया है, मुझे टोकन समाप्त होने से पहले कुछ उपयोगकर्ताओं तक पहुंच से इनकार करना होगा।

— सकर लोपेज

@ ThescarLópez फिर उपयोगकर्ताओं द्वारा उपयोग किए जा रहे टोकन को केवल अमान्य करें। वे अब प्रदान किए गए टोकन (जो अब अमान्य हो चुके हैं) का उपयोग करके एपीआई तक पहुंचने में सक्षम नहीं होंगे और आपको सत्र की आवश्यकता नहीं है।

— एंडी

टोकन क्लाइंट पर संग्रहीत हैं, मैं उन्हें वहां कैसे अमान्य कर सकता हूं? मुझे इस बात का ध्यान रखना होगा कि कौन से वैध हैं ... और यह वह जगह है जहाँ राज्य अपने बदसूरत सिर पर भरोसा करता है। कभी-कभी यह अपरिहार्य है।

— Oscar Lopez

एक दुर्भावनापूर्ण क्लाइंट तब तक के लिए पहले से मान्य टोकन भेज सकता है जब तक उसका समय समाप्त हो जाता है, लेकिन मुझे उसे तुरंत सिस्टम से बाहर निकालने की आवश्यकता होती है - इसलिए एक छोटा नवीनीकरण समय सेट करना भी एक विकल्प नहीं है।

— सकर लोपेज़

@ लैव I ने नोटपैड में अनुक्रम आरेख बनाया।

— एंडी

Answer 3

इसलिए, मैं यह स्वीकार करूंगा कि इससे मुझे कोई मतलब नहीं है कि मैं किस दृष्टिकोण से चिंतित हूं, जब आप पहले से ही सत्र के साथ REST सम्मेलनों को तोड़ रहे हैं, लेकिन मैं समझता हूं कि आपकी व्यावसायिक आवश्यकताओं को पूरा करना है।

REST के दृष्टिकोण से, क्लाइंट या तो प्रमाणीकृत है, या वे नहीं हैं। आर्किटेक्चर बहुत परवाह नहीं करता है कि (यह बेकार की स्थिति को क्यों नियंत्रित करता है), इसलिए आपके मुख्य प्रश्न का उत्तर देने के लिए, मेरे पास बिल्कुल भी समापन बिंदु नहीं होगा। क्लाइंट में एक लॉग हमेशा उनके JWT भेजेगा और सर्वर हमेशा इसे मान्य करता है और या तो कार्रवाई 200, 201, आदि के आधार पर उपयुक्त सफलता कोड भेजकर स्वीकार करता है) या उपयुक्त के रूप में 401 या 403 के साथ अस्वीकार करता है।

अब, JWT किसी प्रकार के खाते से संबद्ध होने जा रहा है। वह खाता लॉक या थ्रॉटल किया जा सकता है या जो भी हो, और इसलिए टोकन स्वयं मान्य हो सकता है लेकिन कार्रवाई अभी भी कहीं और अस्वीकार कर दी गई है। यदि मामला यह है कि उपयोगकर्ता खाता व्यावसायिक नियमों के कारण बंद है, तो यह अभी भी एक 401 या 403 है जो इस बात पर निर्भर करता है कि आप ग्राहक को कितनी जानकारी देना चाहते हैं (विभिन्न व्यवसायों की उस पर अलग-अलग राय है)।

अंत में, यदि आप यह दावा कर रहे हैं कि खाता अनलॉक और मान्य हो सकता है, लेकिन JWT को बस निरस्त करने की आवश्यकता है, तो मैं अभी भी 401 या 403 के साथ रहना चाहूंगा और अमान्य JWTs के प्रमाणपत्र निरस्तीकरण सूची जैसी कुछ चीज़ों को बनाए रख सकता हूँ - जिन्हें आप एक में डाल सकते हैं। , इसलिए जब तक यह स्वयं साफ हो जाता है जब JWT की समय सीमा समाप्त हो जाती है (ज्यादातर डेटाबेस में ऐसा करने का तरीका होता है या आपके पास ऐप कोड में ईवेंट हो सकते हैं)।

Comments

jwt का अर्थ स्टेटलेस होता है। जिस समय आप इसकी सामग्री पर सवाल उठाते हैं और इसे db के विरुद्ध सत्यापित करते हैं, यह अब

— वैधानिक