आपको अपने ASP.NET कोर प्रोजेक्ट में JWT की आवश्यकता क्यों है?

JWT का मतलब JSON वेब टोकन है, और यह एक प्राधिकरण तंत्र है, प्रमाणीकरण नहीं। तो आइए जानें कि उन दोनों में क्या अंतर है।

प्रमाणीकरण वह तंत्र है जो यह सत्यापित करने की अनुमति देता है कि उपयोगकर्ता बिल्कुल वही है जो वह होने का दावा करता है। यह एक लॉगिन प्रक्रिया है जहां एक उपयोगकर्ता एक उपयोगकर्ता नाम और पासवर्ड प्रदान करता है, और सिस्टम उन्हें सत्यापित करता है। तो प्रमाणीकरण इस प्रश्न का उत्तर देता है: उपयोगकर्ता कौन है?

प्राधिकरण वह तंत्र है जो यह सत्यापन करने की अनुमति देता है कि उपयोगकर्ता के पास किसी निश्चित संसाधन तक कौन से पहुंच अधिकार हैं। यह उपयोगकर्ताओं को कुछ भूमिकाएँ और किसी विशेष भूमिका के लिए अनुमतियों का एक सेट देने की एक प्रक्रिया है। तो, प्राधिकरण उस प्रश्न का उत्तर देता है: सिस्टम में उपयोगकर्ता के पास क्या अधिकार हैं?

यह समझना महत्वपूर्ण है कि प्रमाणीकरण हमेशा पहले आता है और प्राधिकरण दूसरे स्थान पर है। दूसरे शब्दों में, अपनी पहचान सत्यापित करने से पहले आपको अनुमति नहीं मिल सकती। लेकिन सबसे लोकप्रिय प्राधिकरण विधियाँ क्या हैं? वेब एप्लिकेशन के लिए प्राधिकरण को संभालने के दो मुख्य दृष्टिकोण हैं।

सत्र

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

टोकन

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

सत्र बनाम टोकन

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

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

दूसरी ओर, टोकन-आधारित प्राधिकरण दृष्टिकोण को सर्वर साइड पर सत्र डेटा संग्रहीत करने की आवश्यकता नहीं होती है और कई सर्वरों के बीच प्राधिकरण को सरल बना सकता है।

हालाँकि, किसी हमलावर द्वारा टोकन अभी भी चुराए जा सकते हैं और टोकन को अमान्य करना भी मुश्किल हो सकता है। हम इस आलेख में विवरण और अमान्यता से निपटने के तरीके को आगे देखेंगे।

जेडब्ल्यूटी

JSON वेब टोकन (JWT) एक खुला मानक है जो JSON ऑब्जेक्ट के रूप में पार्टियों के बीच जानकारी को सुरक्षित रूप से प्रसारित करने के लिए एक कॉम्पैक्ट और स्व-निहित तरीके को परिभाषित करता है। इस जानकारी को सत्यापित और विश्वसनीय किया जा सकता है क्योंकि यह डिजिटल रूप से हस्ताक्षरित है। जेडब्ल्यूटी पर एक गुप्त ( एचएमएसी एल्गोरिदम के साथ) या आरएसए या ईसीडीएसए का उपयोग करके सार्वजनिक/निजी कुंजी जोड़ी का उपयोग करके हस्ताक्षर किए जा सकते हैं।

जेडब्ल्यूटी संरचना

JSON वेब टोकन में डॉट्स द्वारा अलग किए गए तीन भाग होते हैं .

• हैडर

 { "alg": "HS256", "typ": "JWT" }

हेडर में आमतौर पर दो भाग होते हैं: टोकन का प्रकार, और उपयोग किया जा रहा हस्ताक्षर एल्गोरिथ्म।

• पेलोड

 { "sub": "1234567890", "name": "John Doe", "admin": true }

पेलोड में दावे शामिल हैं, जो उपयोगकर्ता के बारे में बयान हैं। फिर JSON वेब टोकन का दूसरा भाग बनाने के लिए पेलोड को Base64Url एनकोड किया जाता है। आप दावे के रूप में उपयोग किए जाने वाले मानक फ़ील्ड का विवरण यहां पा सकते हैं।

• हस्ताक्षर

 HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

हस्ताक्षर भाग बनाने के लिए, आपको एन्कोडेड हेडर, एन्कोडेड पेलोड, एक रहस्य और हेडर में निर्दिष्ट एल्गोरिदम लेना होगा और उस पर हस्ताक्षर करना होगा।

टोकन आम तौर पर निम्नलिखित जैसा दिखता है:

xxxxx.yyyyy.zzzzz

आप jwt.io पर नेविगेट कर सकते हैं और एक नमूना टोकन या अपना खुद का डीबग कर सकते हैं। बस अपने टोकन को एन्कोडेड फ़ील्ड में पेस्ट करें और टोकन हस्ताक्षर के एल्गोरिदम का चयन करें।

.NET प्रोजेक्ट

अब जब हमारे पास JWT कैसे काम करता है इसका सैद्धांतिक ज्ञान है, तो हम इसे वास्तविक जीवन की परियोजना में लागू कर सकते हैं। आइए मान लें कि हमारे पास एक साधारण एपीआई है जो कॉफी इकाई के लिए सीआरयूडी संचालन का प्रतिनिधित्व करती है। हम एक ASP.NET कोर एपीआई प्रोजेक्ट बनाने जा रहे हैं जो कॉफी एपीआई का प्रतिनिधित्व करता है। उसके बाद, हम एक और ASP.NET कोर एपीआई प्रोजेक्ट बनाएंगे जो एक पहचान एपीआई का प्रतिनिधित्व करेगा जो जेडब्ल्यूटी उत्पन्न कर सकता है। वास्तविक जीवन में, आप संभवतः प्रमाणीकरण/प्राधिकरण उद्देश्यों के लिए आइडेंटिटी सर्वर या ओक्टा , या Auth0 का उपयोग करेंगे। हालाँकि, हम JWT उत्पन्न करने का तरीका प्रदर्शित करने के लिए अपनी स्वयं की पहचान API बनाएंगे। जब आइडेंटिटी एपीआई पूरा हो जाता है, तो हम इसके कंट्रोलर को कॉल कर सकते हैं और उपयोगकर्ता के डेटा के आधार पर जेडब्ल्यूटी उत्पन्न कर सकते हैं। इसके अलावा, हम कॉफी एपीआई को एक प्राधिकरण कॉन्फ़िगरेशन के साथ सुरक्षित कर सकते हैं जिसके लिए प्रत्येक अनुरोध के साथ जेडब्ल्यूटी पास करना आवश्यक है।

कॉफ़ी एपीआई

सबसे पहले, हम एक सरल ASP.NET कोर एपीआई प्रोजेक्ट बनाने जा रहे हैं जो कॉफी एपीआई का प्रतिनिधित्व करता है। इस परियोजना की संरचना इस प्रकार है:

आइए Model फ़ोल्डर में Coffee.cs से शुरुआत करें। यह एक Id और Name गुणों वाली एक सरल इकाई है।

 namespace Hackernoon.Coffee.API.Model; public class Coffee { public int Id { get; set; } public string Name { get; set; } }

एपीआई के साथ काम करते समय हमें अपनी इकाइयों को संग्रहीत करने की आवश्यकता है। तो, आइए एक सरल इन-मेमोरी स्टोरेज का परिचय दें। यह Data फ़ोल्डर में Storage.cs फ़ाइल में स्थित है।

 namespace Hackernoon.Coffee.API.Data; public static class Storage { private static readonly List<Model.Coffee> Data = new(); public static List<Model.Coffee> GetAll() { return Data; } public static bool Create(Model.Coffee model) { if (Data.Any(c => c.Id == model.Id || c.Name == model.Name)) return false; Data.Add(new Model.Coffee { Id = model.Id, Name = model.Name }); return true; } public static bool Delete(int id) { if (Data.All(c => c.Id != id)) return false; Data.Remove(Storage.Data.First(c => c.Id == id)); return true; } public static bool Update(Model.Coffee model) { if (Data.All(c => c.Id != model.Id)) return false; Data.First(c => c.Id == model.Id).Name = model.Name; return true; } }

हमें एक ऐसी कक्षा की आवश्यकता है जो कॉफ़ी एपीआई के अनुरोधों का प्रतिनिधित्व करेगी। तो, आइए Contracts फ़ोल्डर में CoffeeRequest.cs बनाएं।

 namespace Hackernoon.Coffee.API.Contracts; public class CoffeeRequest { public int Id { get; set; } public string Name { get; set; } }

जब यह हो जाता है, तो हम Controller फ़ोल्डर में CoffeeController.cs लागू कर सकते हैं जो कॉफ़ी इकाई के लिए CRUD संचालन का प्रतिनिधित्व करता है।

 using Hackernoon.Coffee.API.Contracts; using Hackernoon.Coffee.API.Data; using Microsoft.AspNetCore.Mvc; namespace Hackernoon.Coffee.API.Controllers; [Route("coffee")] [ApiController] public class CoffeeController : ControllerBase { [HttpGet] public IList<Model.Coffee> GetAll() { return Storage.GetAll(); } [HttpPost] public IActionResult Create([FromBody]CoffeeRequest request) { var model = new Model.Coffee { Id = request.Id, Name = request.Name }; if (!Storage.Create(model)) return new BadRequestResult(); return new OkResult(); } [HttpDelete] public IActionResult Delete(int id) { if (!Storage.Delete(id)) return new BadRequestResult(); return new OkResult(); } [HttpPut] public IActionResult Update([FromBody] CoffeeRequest request) { var model = new Model.Coffee() { Id = request.Id, Name = request.Name }; if (!Storage.Update(model)) return new BadRequestResult(); return new OkResult(); } }

कॉफ़ी एपीआई पूरा हो गया है, और हम प्रोजेक्ट चला सकते हैं और स्वैगर यूआई को इस प्रकार देख सकते हैं:

पहचान एपीआई

आइए एक और ASP.NET कोर एपीआई प्रोजेक्ट बनाएं जो आइडेंटिटी एपीआई का प्रतिनिधित्व करता है। इस परियोजना की संरचना इस प्रकार है:

आइए Contracts फ़ोल्डर में TokenGenerationRequest.cs से शुरू करें, जो Email और Password गुणों के साथ एक नई JWT की पीढ़ी के लिए अनुरोध का प्रतिनिधित्व करता है।

 namespace Hackernoon.Identity.API.Contracts; public class TokenGenerationRequest { public string Email { get; set; } public string Password { get; set; } }

हमें केवल TokenController.cs लागू करने की आवश्यकता है जो जेडब्ल्यूटी पीढ़ी के तर्क का प्रतिनिधित्व करता है। लेकिन ऐसा करने से पहले हमें Microsoft.AspNetCore.Authentication.JwtBearer NuGet पैकेज इंस्टॉल करना होगा।

 using System.IdentityModel.Tokens.Jwt; using System.Security.Claims; using System.Text; using Hackernoon.Identity.API.Contracts; using Microsoft.AspNetCore.Mvc; using Microsoft.IdentityModel.Tokens; namespace Hackernoon.Identity.API.Controllers; [Route("token")] public class TokenController : ControllerBase { private const string SecretKey = "VerySecretAndLongKey-NeedMoreSymbolsHere-123"; private const string Issuer = "IdentityServerIssuer"; private const string Audience = "IdentityServerClient"; private static readonly TimeSpan Lifetime = TimeSpan.FromMinutes(20); [HttpPost] public string Create([FromBody]TokenGenerationRequest request) { var claims = new List<Claim> {new Claim(ClaimTypes.Email, request.Email) }; var jwt = new JwtSecurityToken( issuer: Issuer, audience: Audience, claims: claims, expires: DateTime.UtcNow.Add(Lifetime), signingCredentials: CreateSigningCredentials()); return new JwtSecurityTokenHandler().WriteToken(jwt); } private static SigningCredentials CreateSigningCredentials() { return new SigningCredentials( new SymmetricSecurityKey(Encoding.UTF8.GetBytes(SecretKey)), SecurityAlgorithms.HmacSha256); } }

ध्यान दें कि SecretKey , Issuer और Audience जैसे संवेदनशील स्थिरांक को कॉन्फ़िगरेशन में कहीं रखा जाना चाहिए। इस परीक्षण प्रोजेक्ट को सरल बनाने के लिए उन्हें हार्डकोड किया गया है। Lifetime फ़ील्ड को 20 मिनट पर सेट किया गया है, जिसका अर्थ है कि टोकन उस समय के लिए वैध होगा। आप इस पैरामीटर को कॉन्फ़िगर भी कर सकते हैं.

अब हम प्रोजेक्ट चला सकते हैं और स्वैगर यूआई को इस प्रकार देख सकते हैं:

आइए /token एंडपॉइंट पर कॉल करें और एक नया JWT जेनरेट करें। निम्नलिखित पेलोड आज़माएँ:

 { "email": "[email protected]", "password": "password" }

पहचान एपीआई संबंधित JWT उत्पन्न करेगा:

 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9lbWFpbGFkZHJlc3MiOiJqb2huLmRvZUBnbWFpbC5jb20iLCJJc0dvdXJtZXQiOiJmYWxzZSIsImV4cCI6MTcwNzc4Mzk4MCwiaXNzIjoiSWRlbnRpdHlTZXJ2ZXJJc3N1ZXIiLCJhdWQiOiJJZGVudGl0eVNlcnZlckNsaWVudCJ9.4odXsbWak1C0uK3Ux-n7f58icYQQwlHjM54OjgMCVPM

कॉफ़ी एपीआई में प्राधिकरण सक्षम करना

अब, जब आइडेंटिटी एपीआई तैयार है और हमें टोकन प्रदान करता है, तो हम प्राधिकरण के साथ कॉफी एपीआई की रक्षा कर सकते हैं। फिर से Microsoft.AspNetCore.Authentication.JwtBearer NuGet पैकेज को स्थापित करने की आवश्यकता है।

हमें प्रमाणीकरण सेवाओं द्वारा आवश्यक सेवाओं को पंजीकृत करने की आवश्यकता है। बिल्डर बनाने के तुरंत बाद निम्नलिखित कोड को Program.cs फ़ाइल में जोड़ें।

 var builder = WebApplication.CreateBuilder(args); builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options => { options.TokenValidationParameters = new TokenValidationParameters { ValidateIssuer = true, ValidIssuer = "IdentityServerIssuer", ValidateAudience = true, ValidAudience = "IdentityServerClient", ValidateLifetime = true, IssuerSigningKey = new SymmetricSecurityKey( Encoding.UTF8.GetBytes("VerySecretAndLongKey-NeedMoreSymbolsHere-123")), ValidateIssuerSigningKey = true, }; }); builder.Services.AddAuthorization();

यह याद रखना महत्वपूर्ण है कि मिडलवेयर में ऑर्डर महत्वपूर्ण है। हम AddAuthentication() विधि को कॉल करके और JwtBearerDefaults.AuthenticationScheme प्रमाणीकरण स्कीमा के रूप में निर्दिष्ट करके प्रमाणीकरण सक्षम करते हैं। यह एक स्थिरांक है जिसमें एक Bearer मान होता है।

 namespace Microsoft.AspNetCore.Authentication.JwtBearer { /// <summary>Default values used by bearer authentication.</summary> public static class JwtBearerDefaults { /// <summary> /// Default value for AuthenticationScheme property in the JwtBearerAuthenticationOptions /// </summary> public const string AuthenticationScheme = "Bearer"; } }

हमें TokenValidationParameters निर्दिष्ट करने की आवश्यकता है जो बताता है कि प्राधिकरण के दौरान जेडब्ल्यूटी के कौन से पैरामीटर मान्य किए जाएंगे। हम JWT हस्ताक्षर को सत्यापित करने के लिए आइडेंटिटी एपीआई में signingCredentials के समान जारीकर्ता IssuerSigningKey भी निर्दिष्ट करते हैं। TokenValidationParameters के बारे में अधिक विवरण यहां देखें।

कोड का अगला भाग बिल्डर में मिडलवेयर जोड़ता है जो प्रमाणीकरण और प्राधिकरण क्षमताओं को सक्षम बनाता है। इसे UseHttpsRedirection() और MapControllers() तरीकों के बीच जोड़ा जाना चाहिए।

 app.UseHttpsRedirection(); app.UseAuthentication(); app.UseAuthorization(); app.MapControllers();

अब, हम नियंत्रक या उसके कार्यों पर Authorize विशेषता का उपयोग कर सकते हैं। इस कोड को लागू करने से, अब CoffeeController में सभी क्रियाएं एक प्राधिकरण तंत्र के साथ सुरक्षित हैं, और JWT को अनुरोध के एक भाग के रूप में भेजा जाना है।

 [Route("coffee")] [ApiController] [Authorize] public class CoffeeController : ControllerBase { ..

यदि हम कॉफ़ी एपीआई के किसी भी समापन बिंदु पर कॉल करते हैं, तो हम HttpContext.User डीबग कर सकते हैं और देख सकते हैं कि यह पॉप्युलेट हो गया है और हमारे पास JWT में निर्दिष्ट दावों के साथ एक Identity है। यह समझने में एक महत्वपूर्ण बात है कि ASP.NET कोर हुड के तहत प्राधिकरण को कैसे संभालता है।

स्वैगर यूआई में प्राधिकरण जोड़ें

हमने प्राधिकरण के साथ कॉफी एपीआई की सुरक्षा के लिए बहुत अच्छा काम किया। लेकिन यदि आप कॉफी एपीआई प्रोजेक्ट चलाते हैं और स्वैगर यूआई खोलते हैं, तो आप अनुरोध के हिस्से के रूप में जेडब्ल्यूटी नहीं भेज पाएंगे। इसे ठीक करने के लिए, हमें निम्नलिखित कोड के साथ Program.cs फ़ाइल को अपडेट करना होगा:

 builder.Services.AddSwaggerGen(option => { option.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme { In = ParameterLocation.Header, Description = "Please enter a valid token", Name = "Authorization", Type = SecuritySchemeType.Http, BearerFormat = "JWT", Scheme = "Bearer" }); option.AddSecurityRequirement(new OpenApiSecurityRequirement { { new OpenApiSecurityScheme { Reference = new OpenApiReference { Type=ReferenceType.SecurityScheme, Id="Bearer" } }, new string[]{} } }); });

उसके बाद, हम दाएं शीर्ष कोने पर अधिकृत बटन देख पाएंगे:

जब आप अधिकृत बटन पर क्लिक करेंगे तो आप निम्नानुसार जेडब्ल्यूटी दर्ज कर सकेंगे:

परीक्षण के लिए पोस्टमैन का प्रयोग करें

आप स्वैगर यूआई का उपयोग करने तक खुद को सीमित नहीं कर सकते हैं और पोस्टमैन टूल के माध्यम से एपीआई का परीक्षण कर सकते हैं। आइए पहले आइडेंटिटी एपीआई के /token एंडपॉइंट पर कॉल करें। हमें हेडर अनुभाग में वैल्यू application/json के साथ Content-Type हेडर निर्दिष्ट करने की आवश्यकता है क्योंकि हम जेएसओएन को पेलोड के रूप में उपयोग करने जा रहे हैं।

उसके बाद, हम /token एंडपॉइंट पर कॉल कर सकते हैं और एक नया JWT प्राप्त कर सकते हैं।

अब, हम JWT की प्रतिलिपि बना सकते हैं और कॉफ़ी एपीआई को कॉल करने के लिए इसका उपयोग कर सकते हैं। यदि हम एंडपॉइंट का परीक्षण करना, बनाना और अपडेट करना चाहते हैं तो हमें आइडेंटिटी एपीआई के समान Content-Type हेडर निर्दिष्ट करने की आवश्यकता है। Authorization हेडर को भी Bearer [your JWT value] मान के साथ सेट करना होगा। उसके बाद, बस भेजें बटन दबाएं और परिणाम देखें।

भूमिका-आधारित प्राधिकरण

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

यदि हम आइडेंटिटी एपीआई में TokenController.cs फ़ाइल में Create() विधि को उस कोड के साथ अपडेट करते हैं जो भूमिका के लिए एक नया दावा जोड़ता है; हम कॉफ़ी एपीआई में भूमिका-आधारित प्रमाणीकरण संभाल सकते हैं। ClaimTypes.Role , भूमिका दावे का एक पूर्वनिर्धारित नाम है।

 var claims = new List<Claim> { new Claim(ClaimTypes.Email, request.Email), new Claim(ClaimTypes.Role, "Barista") };

भूमिका नाम निर्दिष्ट करते हुए CoffeeController.cs फ़ाइल में Authorize विशेषता को अद्यतन करें:

 [Authorize(Roles = "Barista")]

अब, कॉफ़ी एपीआई पर कॉल करने वाले सभी उपयोगकर्ताओं के पास Barista मान के साथ भूमिका का दावा होना चाहिए। अन्यथा, उन्हें 403 Forbidden स्थिति कोड मिलेगा।

दावा-आधारित प्राधिकरण

एक Authorize विशेषता आसानी से भूमिका-आधारित प्रमाणीकरण को संभाल सकती है। लेकिन क्या होगा यदि यह पर्याप्त नहीं है, और हम कुछ उपयोगकर्ता गुणों जैसे उम्र या किसी अन्य के आधार पर पहुंच में अंतर करना चाहते हैं? आपने शायद पहले ही अनुमान लगा लिया है कि आप अपने दावे JWT में जोड़ सकते हैं और प्राधिकरण तर्क बनाने के लिए उनका उपयोग कर सकते हैं। भूमिका-आधारित प्राधिकरण स्वयं दावा-आधारित प्राधिकरण का एक विशेष मामला है, जैसे भूमिका पूर्वनिर्धारित प्रकार की समान दावा वस्तु है।

आइए आइडेंटिटी एपीआई में TokenController.cs फ़ाइल में Create() विधि को उस कोड के साथ अपडेट करें जो एक नया दावा IsGourmet जोड़ता है।

 var claims = new List<Claim> { new Claim(ClaimTypes.Email, request.Email), new Claim("IsGourmet", "true") };

कॉफ़ी एपीआई में प्रोग्राम.सीएस फ़ाइल में, हमें एक नीति बनाने की ज़रूरत है जो दावे को सत्यापित करती है और इसे Authorize विशेषता में उपयोग किया जा सकता है। निम्नलिखित कोड को AddAuthentication() विधि कॉल के ठीक बाद जोड़ा जाना चाहिए।

 builder.Services.AddAuthorization(opts => { opts.AddPolicy("OnlyForGourmet", policy => { policy.RequireClaim("IsGourmet", "true"); }); });

पॉलिसी नाम निर्दिष्ट करते हुए CoffeeController.cs फ़ाइल में Authorize विशेषता को अपडेट करें:

 [Authorize(Policy = "OnlyForGourmet")]

सारांश

बधाई हो! आपने .NET में JWT सीखने का बहुत अच्छा प्रयास किया। अब, आपको JWT सिद्धांतों की ठोस समझ होनी चाहिए और .NET अनुप्रयोगों में प्राधिकरण करने के लिए इसका उपयोग करना क्यों महत्वपूर्ण है। लेकिन हमने ASP.NET कोर अनुप्रयोगों में प्रमाणीकरण और प्राधिकरण के क्षेत्र में केवल सतह को खंगाला है।

मेरा सुझाव है कि इस आलेख में जिन विषयों पर हमने चर्चा की है, उनके संबंध में Microsoft दस्तावेज़ देखें। .NET प्लेटफ़ॉर्म में प्राधिकरण और भूमिका प्रबंधन के लिए बहुत सारी अंतर्निहित क्षमताएं भी हैं। प्राधिकरण के बारे में Microsoft दस्तावेज़ीकरण इस आलेख में एक अच्छा जोड़ हो सकता है।