मैंने ताइसेर के सुझाव पर अपना दृष्टिकोण आधारित किया है। समाधान का सारांश निम्नलिखित है। प्रत्येक बार जब कोई उपयोगकर्ता अपना पासवर्ड बदलता है (और जब पंजीयक), तो एक नया GUID उत्पन्न होता है और उपयोगकर्ता तालिका में डेटाबेस में सहेजा जाता है। मैं इस GUID को पासवर्ड स्टैम्प पर कॉल करता हूं, और इसे LatestPasswordStamp नामक संपत्ति में संग्रहीत करता हूं।
इस टिकट को दावे के हिस्से के रूप में टोकन के हिस्से के रूप में ग्राहक को भेजना होगा। यह OAuthAuthorizationServerProvider-कार्यान्वयन के GrantResourceOwnerCredentials विधि में निम्न कोड के साथ प्राप्त किया जा सकता है।
identity.AddClaim(new Claim("PasswordTokenClaim", user.LatestPasswordStamp.ToString()));
यह डाक टिकट हर अनुरोध में क्लाइंट से सर्वर तक भेजे जाने के लिए जा रहा है, और यह सत्यापित किया गया है कि टिकट डेटाबेस में नहीं बदला गया है। यदि ऐसा होता है, तो इसका मतलब है कि उपयोगकर्ता ने अपना पासवर्ड बदल दिया, संभवतः किसी अन्य डिवाइस से। सत्यापन इस तरह हमारे कस्टम प्राधिकरण फ़िल्टर में किया जाता है।
public class AuthorizeAndCheckStampAttribute : AuthorizeAttribute
{
public override void OnAuthorization(HttpActionContext actionContext)
{
var claimsIdentity = actionContext.RequestContext.Principal.Identity as ClaimsIdentity;
if(claimsIdentity == null)
{
this.HandleUnauthorizedRequest(actionContext);
}
// Check if the password has been changed. If it was, this token should be not accepted any more.
// We generate a GUID stamp upon registration and every password change, and put it in every token issued.
var passwordTokenClaim = claimsIdentity.Claims.FirstOrDefault(c => c.Type == "PasswordTokenClaim");
if(passwordTokenClaim == null)
{
// There was no stamp in the token.
this.HandleUnauthorizedRequest(actionContext);
}
else
{
MyContext ctx = (MyContext)System.Web.Mvc.DependencyResolver.Current.GetService(typeof(MyContext));
var userName = claimsIdentity.Claims.First(c => c.Type == ClaimTypes.Name).Value;
if(ctx.Users.First(u => u.UserName == userName).LatestPasswordStamp.ToString() != passwordTokenClaim.Value)
{
// The stamp has been changed in the DB.
this.HandleUnauthorizedRequest(actionContext);
}
}
base.OnAuthorization(actionContext);
}
}
इस तरह अगर यह एक टोकन जो पहले पासवर्ड बदल दिया गया जारी किया गया था के साथ खुद को अधिकृत करने के लिए कोशिश करता है ग्राहक प्रमाणीकरण त्रुटि हो जाता है।
स्रोत
2014-11-18 20:52:32
ओएथ के साथ बिंदु का हिस्सा नहीं है कि यह पासवर्ड परिवर्तनों पर स्वतंत्र है? जब वे पासवर्ड बदलते हैं तो अपने प्रमाणीकरण सर्वर से टोकन को न हटाएं, फिर यदि वे कोशिश करते हैं और अन्य उपकरणों पर इसका उपयोग करते हैं तो यह काम नहीं करेगा। – DaImTo
"क्यों न केवल अपने प्रमाणीकरण सर्वर से टोकन हटाएं": क्या यह एएसपी.NET पहचान के साथ संभव है? मैंने सोचा कि टोकन स्वयं निहित हैं, इसलिए उन्हें किसी भी वेब-सर्वर उदाहरण पर उपयोग किया जा सकता है, इस प्रकार हमारे पास प्रमाणीकरण सर्वर नहीं है। –
यदि यह सच है तो ऐसा लगता है कि मुझे "एएसपी.नेट पहचान" पर एक ताज़ा करने की आवश्यकता है। माफ़ कीजिये। – DaImTo