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 कोर एपीआई प्रोजेक्ट बनाएंगे जो एक पहचान एपीआई का प्रतिनिधित्व करेगा जो जेडब्ल्यूटी उत्पन्न कर सकता है। वास्तविक जीवन में, आप संभवतः प्रमाणीकरण/प्राधिकरण उद्देश्यों के लिए या , या का उपयोग करेंगे। हालाँकि, हम JWT उत्पन्न करने का तरीका प्रदर्शित करने के लिए अपनी स्वयं की पहचान API बनाएंगे। जब आइडेंटिटी एपीआई पूरा हो जाता है, तो हम इसके कंट्रोलर को कॉल कर सकते हैं और उपयोगकर्ता के डेटा के आधार पर जेडब्ल्यूटी उत्पन्न कर सकते हैं। इसके अलावा, हम कॉफी एपीआई को एक प्राधिकरण कॉन्फ़िगरेशन के साथ सुरक्षित कर सकते हैं जिसके लिए प्रत्येक अनुरोध के साथ जेडब्ल्यूटी पास करना आवश्यक है। आइडेंटिटी सर्वर ओक्टा Auth0 कॉफ़ी एपीआई सबसे पहले, हम एक सरल 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; } } जब यह हो जाता है, तो हम फ़ोल्डर में लागू कर सकते हैं जो कॉफ़ी इकाई के लिए CRUD संचालन का प्रतिनिधित्व करता है। Controller CoffeeController.cs 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 कोर एपीआई प्रोजेक्ट बनाएं जो आइडेंटिटी एपीआई का प्रतिनिधित्व करता है। इस परियोजना की संरचना इस प्रकार है: आइए फ़ोल्डर में से शुरू करें, जो और गुणों के साथ एक नई JWT की पीढ़ी के लिए अनुरोध का प्रतिनिधित्व करता है। Contracts TokenGenerationRequest.cs Email Password namespace Hackernoon.Identity.API.Contracts; public class TokenGenerationRequest { public string Email { get; set; } public string Password { get; set; } } हमें केवल लागू करने की आवश्यकता है जो जेडब्ल्यूटी पीढ़ी के तर्क का प्रतिनिधित्व करता है। लेकिन ऐसा करने से पहले हमें NuGet पैकेज इंस्टॉल करना होगा। TokenController.cs Microsoft.AspNetCore.Authentication.JwtBearer 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); } } ध्यान दें कि , और जैसे संवेदनशील स्थिरांक को कॉन्फ़िगरेशन में कहीं रखा जाना चाहिए। इस परीक्षण प्रोजेक्ट को सरल बनाने के लिए उन्हें हार्डकोड किया गया है। फ़ील्ड को 20 मिनट पर सेट किया गया है, जिसका अर्थ है कि टोकन उस समय के लिए वैध होगा। आप इस पैरामीटर को कॉन्फ़िगर भी कर सकते हैं. SecretKey Issuer Audience Lifetime अब हम प्रोजेक्ट चला सकते हैं और स्वैगर यूआई को इस प्रकार देख सकते हैं: आइए एंडपॉइंट पर कॉल करें और एक नया JWT जेनरेट करें। निम्नलिखित पेलोड आज़माएँ: /token { "email": "john.doe@gmail.com", "password": "password" } पहचान एपीआई संबंधित JWT उत्पन्न करेगा: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9lbWFpbGFkZHJlc3MiOiJqb2huLmRvZUBnbWFpbC5jb20iLCJJc0dvdXJtZXQiOiJmYWxzZSIsImV4cCI6MTcwNzc4Mzk4MCwiaXNzIjoiSWRlbnRpdHlTZXJ2ZXJJc3N1ZXIiLCJhdWQiOiJJZGVudGl0eVNlcnZlckNsaWVudCJ9.4odXsbWak1C0uK3Ux-n7f58icYQQwlHjM54OjgMCVPM कॉफ़ी एपीआई में प्राधिकरण सक्षम करना अब, जब आइडेंटिटी एपीआई तैयार है और हमें टोकन प्रदान करता है, तो हम प्राधिकरण के साथ कॉफी एपीआई की रक्षा कर सकते हैं। फिर से NuGet पैकेज को स्थापित करने की आवश्यकता है। Microsoft.AspNetCore.Authentication.JwtBearer हमें प्रमाणीकरण सेवाओं द्वारा आवश्यक सेवाओं को पंजीकृत करने की आवश्यकता है। बिल्डर बनाने के तुरंत बाद निम्नलिखित कोड को फ़ाइल में जोड़ें। 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"; } } हमें निर्दिष्ट करने की आवश्यकता है जो बताता है कि प्राधिकरण के दौरान जेडब्ल्यूटी के कौन से पैरामीटर मान्य किए जाएंगे। हम JWT हस्ताक्षर को सत्यापित करने के लिए आइडेंटिटी एपीआई में के समान जारीकर्ता भी निर्दिष्ट करते हैं। के बारे में अधिक विवरण देखें। TokenValidationParameters signingCredentials IssuerSigningKey TokenValidationParameters यहां कोड का अगला भाग बिल्डर में मिडलवेयर जोड़ता है जो प्रमाणीकरण और प्राधिकरण क्षमताओं को सक्षम बनाता है। इसे और तरीकों के बीच जोड़ा जाना चाहिए। UseHttpsRedirection() MapControllers() app.UseHttpsRedirection(); app.UseAuthentication(); app.UseAuthorization(); app.MapControllers(); अब, हम नियंत्रक या उसके कार्यों पर विशेषता का उपयोग कर सकते हैं। इस कोड को लागू करने से, अब में सभी क्रियाएं एक प्राधिकरण तंत्र के साथ सुरक्षित हैं, और JWT को अनुरोध के एक भाग के रूप में भेजा जाना है। Authorize CoffeeController [Route("coffee")] [ApiController] [Authorize] public class CoffeeController : ControllerBase { .. यदि हम कॉफ़ी एपीआई के किसी भी समापन बिंदु पर कॉल करते हैं, तो हम डीबग कर सकते हैं और देख सकते हैं कि यह पॉप्युलेट हो गया है और हमारे पास JWT में निर्दिष्ट दावों के साथ एक है। यह समझने में एक महत्वपूर्ण बात है कि ASP.NET कोर हुड के तहत प्राधिकरण को कैसे संभालता है। HttpContext.User Identity स्वैगर यूआई में प्राधिकरण जोड़ें हमने प्राधिकरण के साथ कॉफी एपीआई की सुरक्षा के लिए बहुत अच्छा काम किया। लेकिन यदि आप कॉफी एपीआई प्रोजेक्ट चलाते हैं और स्वैगर यूआई खोलते हैं, तो आप अनुरोध के हिस्से के रूप में जेडब्ल्यूटी नहीं भेज पाएंगे। इसे ठीक करने के लिए, हमें निम्नलिखित कोड के साथ फ़ाइल को अपडेट करना होगा: 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 उसके बाद, हम एंडपॉइंट पर कॉल कर सकते हैं और एक नया JWT प्राप्त कर सकते हैं। /token अब, हम 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 दावा-आधारित प्राधिकरण एक विशेषता आसानी से भूमिका-आधारित प्रमाणीकरण को संभाल सकती है। लेकिन क्या होगा यदि यह पर्याप्त नहीं है, और हम कुछ उपयोगकर्ता गुणों जैसे उम्र या किसी अन्य के आधार पर पहुंच में अंतर करना चाहते हैं? आपने शायद पहले ही अनुमान लगा लिया है कि आप अपने दावे JWT में जोड़ सकते हैं और प्राधिकरण तर्क बनाने के लिए उनका उपयोग कर सकते हैं। भूमिका-आधारित प्राधिकरण स्वयं दावा-आधारित प्राधिकरण का एक विशेष मामला है, जैसे भूमिका पूर्वनिर्धारित प्रकार की समान दावा वस्तु है। Authorize आइए आइडेंटिटी एपीआई में फ़ाइल में विधि को उस कोड के साथ अपडेट करें जो एक नया दावा जोड़ता है। 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 इस आलेख में एक अच्छा जोड़ हो सकता है। दस्तावेज़ीकरण
