JWT মানে , এবং এটি একটি অনুমোদন প্রক্রিয়া, প্রমাণীকরণ নয়। তো চলুন জেনে নেওয়া যাক সেই দুটির মধ্যে পার্থক্য কী। JSON ওয়েব টোকেন হল এমন একটি পদ্ধতি যা যাচাই করার অনুমতি দেয় যে ব্যবহারকারী ঠিক সেই ব্যক্তি যাকে তিনি দাবি করেন। এটি একটি লগইন প্রক্রিয়া যেখানে একজন ব্যবহারকারী একটি ব্যবহারকারীর নাম এবং পাসওয়ার্ড প্রদান করে এবং সিস্টেম তাদের যাচাই করে। তাই প্রমাণীকরণ প্রশ্নের উত্তর দেয়: ব্যবহারকারী কে? প্রমাণীকরণ হল এমন একটি প্রক্রিয়া যা ব্যবহারকারীর কোন নির্দিষ্ট সংস্থানগুলিতে অ্যাক্সেসের অধিকার রয়েছে তা যাচাই করার অনুমতি দেয়। এটি ব্যবহারকারীদের কিছু ভূমিকা প্রদান করার একটি প্রক্রিয়া এবং একটি নির্দিষ্ট ভূমিকার অনুমতিগুলির একটি সেট৷ সুতরাং, অনুমোদন সেই প্রশ্নের উত্তর দেয়: সিস্টেমে ব্যবহারকারীর কি অধিকার আছে? অনুমোদন এটা বোঝা গুরুত্বপূর্ণ যে প্রমাণীকরণ সর্বদা প্রথম আসে এবং অনুমোদন দ্বিতীয়। অন্য কথায়, আপনি আপনার পরিচয় যাচাই করার আগে অনুমতি পেতে পারবেন না। কিন্তু সবচেয়ে জনপ্রিয় অনুমোদন পদ্ধতি কি কি? ওয়েব অ্যাপ্লিকেশনের জন্য অনুমোদন পরিচালনা করার দুটি প্রধান পদ্ধতি রয়েছে। সেশন অনুমোদন ব্যবহারকারীদের জন্য ওয়েবে একটি ঐতিহ্যগত পদ্ধতি হল একটি কুকি-ভিত্তিক সার্ভার-সাইড সেশন। প্রক্রিয়াটি শুরু হয় যখন একজন ব্যবহারকারী লগ ইন করে এবং একটি সার্ভার তাকে প্রমাণীকরণ করে। এর পরে, সার্ভার একটি সেশন আইডি সহ একটি সেশন তৈরি করে এবং এটি সার্ভারের মেমরিতে কোথাও সংরক্ষণ করে। সার্ভার ক্লায়েন্টকে সেশন আইডি ফেরত পাঠায় এবং ক্লায়েন্ট কুকিতে সেশন আইডি সংরক্ষণ করে। প্রতিটি অনুরোধের জন্য, ক্লায়েন্ট অনুরোধের অংশ হিসাবে একটি সেশন আইডি পাঠায় এবং সার্ভার তার মেমরিতে থাকা সেশন আইডি এবং এই সেশনের সাথে সম্পর্কিত ব্যবহারকারীর অনুমতি যাচাই করে। টোকেন আরেকটি জনপ্রিয় পদ্ধতি হল অনুমোদনের জন্য টোকেন ব্যবহার করা। প্রক্রিয়া একইভাবে শুরু হয় যখন একজন ব্যবহারকারী লগইন প্রবেশ করে, এবং পাসওয়ার্ড এবং একটি ক্লায়েন্ট একটি সার্ভারে একটি লগইন অনুরোধ পাঠায়। একটি সেশন তৈরি করার পরিবর্তে, সার্ভার গোপন টোকেন সহ স্বাক্ষরিত একটি টোকেন তৈরি করে। তারপর, সার্ভার ক্লায়েন্টের কাছে টোকেনটি ফেরত পাঠায় এবং ক্লায়েন্টকে স্থানীয় স্টোরেজে সংরক্ষণ করতে হবে। সেশন-ভিত্তিক পদ্ধতির মতো, ক্লায়েন্টকে প্রতিটি অনুরোধের জন্য সার্ভারে একটি টোকেন পাঠাতে হবে। যাইহোক, সার্ভার ব্যবহারকারীর সেশন সম্পর্কে কোনো অতিরিক্ত তথ্য সংরক্ষণ করে না। সার্ভারকে যাচাই করতে হবে যে টোকেনটি তৈরি এবং গোপন কী দিয়ে স্বাক্ষর করার পর থেকে এটি পরিবর্তিত হয়নি। সেশন বনাম টোকেন সেশন-ভিত্তিক অনুমোদন পদ্ধতি ক্রস-সাইট রিকোয়েস্ট ফোরজি (CSRF) নামে পরিচিত আক্রমণের জন্য ঝুঁকিপূর্ণ হতে পারে। এটি এক ধরনের আক্রমণ যখন আক্রমণকারী এমন একটি সাইটের দিকে নির্দেশ করে যেটিতে তারা লগ ইন করা কাজগুলি সম্পাদন করার জন্য তারা যা করতে চায় না, যেমন একটি অর্থপ্রদান জমা দেওয়া বা পাসওয়ার্ড পরিবর্তন করা। আরেকটি বিষয় হল যখন একটি সেশন-ভিত্তিক অনুমোদন পদ্ধতি ব্যবহার করে একটি ক্লায়েন্ট এবং সার্ভারের মধ্যে একটি রাষ্ট্রীয় অধিবেশন তৈরি করে। সমস্যা হল যদি একজন ক্লায়েন্ট একই অ্যাপ্লিকেশনের সুযোগে বিভিন্ন সার্ভার অ্যাক্সেস করতে চায়, সেই সার্ভারগুলিকে একটি সেশন স্টেট শেয়ার করতে হবে। অন্য ক্ষেত্রে, ক্লায়েন্টকে প্রতিটি সার্ভারে অনুমোদিত হতে হবে যেহেতু সেশনটি আলাদা হতে চলেছে। অন্যদিকে, টোকেন-ভিত্তিক অনুমোদন পদ্ধতির জন্য সার্ভারের পাশে সেশন ডেটা সংরক্ষণের প্রয়োজন হয় না এবং একাধিক সার্ভারের মধ্যে অনুমোদনকে সহজ করতে পারে। যাইহোক, টোকেনগুলি এখনও আক্রমণকারী চুরি করতে পারে এবং টোকেনগুলিকে বাতিল করাও কঠিন হতে পারে৷ আমরা এই নিবন্ধে আরও বিশদ বিবরণ এবং কীভাবে অবৈধতা পরিচালনা করব তা দেখব। জেডব্লিউটি JSON ওয়েব টোকেন (JWT) হল একটি উন্মুক্ত মান যা একটি JSON অবজেক্ট হিসাবে পক্ষগুলির মধ্যে নিরাপদে তথ্য প্রেরণের জন্য একটি কম্প্যাক্ট এবং স্বয়ংসম্পূর্ণ উপায় সংজ্ঞায়িত করে। এই তথ্য যাচাই এবং বিশ্বাস করা যেতে পারে কারণ এটি ডিজিটাল স্বাক্ষরিত। JWTs একটি গোপন ( অ্যালগরিদম সহ) বা বা ব্যবহার করে একটি পাবলিক/প্রাইভেট কী জোড়া ব্যবহার করে স্বাক্ষর করা যেতে পারে। HMAC RSA ECDSA JWT কাঠামো 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 কীভাবে কাজ করে সে সম্পর্কে তাত্ত্বিক জ্ঞান আছে, আমরা এটি বাস্তব-জীবনের প্রকল্পে প্রয়োগ করতে পারি। ধরা যাক আমাদের কাছে একটি সাধারণ API আছে যা কফি সত্তার জন্য CRUD ক্রিয়াকলাপ উপস্থাপন করে। আমরা একটি ASP.NET Core API প্রকল্প তৈরি করতে যাচ্ছি যা Coffee API প্রতিনিধিত্ব করে। এর পরে, আমরা আরেকটি ASP.NET কোর API প্রকল্প তৈরি করব যা একটি আইডেন্টিটি API প্রতিনিধিত্ব করবে যা JWT তৈরি করতে পারে। বাস্তব জীবনে, আপনি সম্ভবত প্রমাণীকরণ/অনুমোদনের উদ্দেশ্যে বা বা ব্যবহার করবেন। যাইহোক, কীভাবে JWT তৈরি করতে হয় তা প্রদর্শন করতে আমরা আমাদের নিজস্ব আইডেন্টিটি API তৈরি করব। আইডেন্টিটি এপিআই হয়ে গেলে, আমরা এর কন্ট্রোলারকে কল করতে পারি এবং ব্যবহারকারীর ডেটার উপর ভিত্তি করে JWT তৈরি করতে পারি। এছাড়াও, আমরা একটি অনুমোদন কনফিগারেশনের সাথে কফি API রক্ষা করতে পারি যার জন্য প্রতিটি অনুরোধের সাথে JWT পাস করতে হবে। আইডেন্টিটি সার্ভার Okta Auth0 কফি API প্রথমত, আমরা একটি সাধারণ ASP.NET Core API প্রজেক্ট তৈরি করতে যাচ্ছি যা Coffee API প্রতিনিধিত্ব করে। এই প্রকল্পের কাঠামো এখানে: ফোল্ডারে দিয়ে শুরু করা যাক। এটি একটি এবং একটি বৈশিষ্ট্য সহ একটি সাধারণ সত্তা৷ Model Coffee.cs Id Name namespace Hackernoon.Coffee.API.Model; public class Coffee { public int Id { get; set; } public string Name { get; set; } } API এর সাথে কাজ করার সময় আমাদের সত্তাগুলি সংরক্ষণ করতে হবে। সুতরাং, আসুন একটি সাধারণ ইন-মেমরি স্টোরেজ প্রবর্তন করি। এটি ফোল্ডারের ফাইলে অবস্থিত। 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(); } } কফি API সম্পন্ন হয়েছে, এবং আমরা প্রকল্পটি চালাতে পারি এবং নিম্নরূপ Swagger UI দেখতে পারি: আইডেন্টিটি API আসুন আরেকটি ASP.NET Core API প্রকল্প তৈরি করি যা Identity API প্রতিনিধিত্ব করে। এই প্রকল্পের কাঠামো এখানে: আসুন ফোল্ডারে দিয়ে শুরু করি, যা এবং বৈশিষ্ট্য সহ একটি নতুন 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 এখন আমরা প্রকল্পটি চালাতে পারি এবং নিম্নরূপ Swagger UI দেখতে পারি: আসুন এন্ডপয়েন্টে একটি কল করি এবং একটি নতুন JWT তৈরি করি। নিম্নলিখিত পেলোড চেষ্টা করুন: /token { "email": "john.doe@gmail.com", "password": "password" } আইডেন্টিটি এপিআই সংশ্লিষ্ট JWT তৈরি করবে: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9lbWFpbGFkZHJlc3MiOiJqb2huLmRvZUBnbWFpbC5jb20iLCJJc0dvdXJtZXQiOiJmYWxzZSIsImV4cCI6MTcwNzc4Mzk4MCwiaXNzIjoiSWRlbnRpdHlTZXJ2ZXJJc3N1ZXIiLCJhdWQiOiJJZGVudGl0eVNlcnZlckNsaWVudCJ9.4odXsbWak1C0uK3Ux-n7f58icYQQwlHjM54OjgMCVPM কফি API-তে অনুমোদন সক্ষম করা হচ্ছে এখন, যখন আইডেন্টিটি এপিআই প্রস্তুত হয় এবং আমাদেরকে টোকেন প্রদান করে, আমরা অনুমোদনের সাথে কফি এপিআই রক্ষা করতে পারি। আবার 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-এর কোন প্যারামিটারগুলি যাচাই করা হবে। আমরা JWT স্বাক্ষর যাচাই করার জন্য Identity API-এ এর মতো নির্দিষ্ট করি। সম্পর্কে আরো বিস্তারিত দেখুন। 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 Swagger UI এ অনুমোদন যোগ করুন আমরা অনুমোদনের সাথে কফি API রক্ষা করার জন্য দুর্দান্ত কাজ করেছি। কিন্তু আপনি যদি কফি API প্রজেক্ট চালান এবং Swagger UI খুলেন, তাহলে অনুরোধের অংশ হিসেবে আপনি JWT পাঠাতে পারবেন না। এটি ঠিক করতে, আমাদের নিম্নলিখিত কোড সহ ফাইলটি আপডেট করতে হবে: 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[]{} } }); }); এর পরে, আমরা ডান উপরের কোণে বোতামটি দেখতে সক্ষম হব: অনুমোদন আপনি যখন বোতামে ক্লিক করবেন তখন আপনি JWT-এ প্রবেশ করতে পারবেন: অনুমোদন পরীক্ষার জন্য পোস্টম্যান ব্যবহার করুন আপনি Swagger UI ব্যবহার করে নিজেকে সীমাবদ্ধ করতে পারবেন না এবং পোস্টম্যান টুলের মাধ্যমে API এর পরীক্ষা করতে পারেন। প্রথমে আইডেন্টিটি এপিআই এর এন্ডপয়েন্ট কল করি। আমাদের বিভাগে মান সহ শিরোনাম নির্দিষ্ট করতে হবে যেহেতু আমরা একটি পেলোড হিসাবে JSON ব্যবহার করতে যাচ্ছি। /token হেডার application/json Content-Type এর পরে, আমরা এন্ডপয়েন্টে কল করতে পারি এবং একটি নতুন JWT পেতে পারি। /token এখন, আমরা JWT অনুলিপি করতে পারি এবং কফি API কল করতে এটি ব্যবহার করতে পারি। আমরা যদি এন্ডপয়েন্ট পরীক্ষা করতে, তৈরি করতে এবং আপডেট করতে চাই তাহলে আমাদের আইডেন্টিটি API-এর মতো শিরোনাম নির্দিষ্ট করতে হবে। শিরোনামটিও মান দিয়ে সেট করতে হবে। এর পরে, শুধু বোতাম টিপুন এবং ফলাফল দেখুন। Content-Type Authorization Bearer [your JWT value] পাঠান ভূমিকা-ভিত্তিক অনুমোদন আপনার মনে আছে, JWT-এর পেলোড অংশ হল মূল্যগুলির সাথে দাবির একটি সেট যা ঠিক কী-মান জোড়া। ভূমিকা-ভিত্তিক অনুমোদন আপনাকে ব্যবহারকারীর ভূমিকার উপর নির্ভর করে অ্যাপ্লিকেশন সংস্থানগুলিতে অ্যাক্সেসের পার্থক্য করতে দেয়। যদি আমরা আইডেন্টিটি API-তে ফাইলে পদ্ধতি আপডেট করি সেই কোডের সাথে যা ভূমিকার জন্য একটি নতুন দাবি যোগ করে; আমরা Coffee API-এ ভূমিকা-ভিত্তিক প্রমাণীকরণ পরিচালনা করতে পারি। হল ভূমিকা দাবির একটি পূর্বনির্ধারিত নাম। 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") }; Coffee API-এর Program.cs ফাইলে, আমাদের একটি নীতি তৈরি করতে হবে যা একটি দাবি যাচাই করে এবং বৈশিষ্ট্যে ব্যবহার করা যেতে পারে। মেথড কলের ঠিক পরে নিচের কোডটি যোগ করতে হবে। 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 কোর অ্যাপ্লিকেশনগুলিতে প্রমাণীকরণ এবং অনুমোদনের ক্ষেত্রে পৃষ্ঠটি স্ক্র্যাচ করেছি। আমরা এই নিবন্ধে যে বিষয়গুলি নিয়ে আলোচনা করেছি সেগুলি সম্পর্কে আমি মাইক্রোসফ্ট ডকুমেন্টেশন দেখার পরামর্শ দিচ্ছি। এছাড়াও .NET প্ল্যাটফর্মে অনুমোদন এবং ভূমিকা পরিচালনার জন্য প্রচুর অন্তর্নির্মিত ক্ষমতা রয়েছে। এই নিবন্ধের একটি ভাল সংযোজন অনুমোদন সম্পর্কে মাইক্রোসফ্ট হতে পারে। ডকুমেন্টেশন
