I used Identity Server and protected endpoints with policies and roles. Those are reflected in the access token I'm distributing to the client. Today, I got the suggestion that instead of protecting a method like this:
[Authorize(Policy = "Elevated"), HttpGet("metadata")]
public IActionResult GetTenantMetadata() { ... }
we could skip the role section of the JWT and only do the following.
[Authorize, HttpGet("metadata")]
public IActionResult GetTenantMetadata() { ... }
Then, in the Startup.cs, we'd register a custom handler like this.
services.AddHttpContextAccessor();
services.AddTransient<IAuthorizationHandler, HeaderHandler>();
The actual security would be then performed in the handler based on the sub value from the token. No roles, no scopes no nothing. To me, it appears intuitively ill-advised putting a lot of responsibility on me to create the protective logic, instead of relying on IDS and people way smarter than me. All the solutions I've seen deal with security using claims and roles. So my gut feeling says it's a bad idea.
protected override Task HandleRequirementAsync(
AuthorizationHandlerContext context,
CustomRequirement requirement)
{
HttpRequest request = Accessor.HttpContext.Request;
string param = request.Headers.SingleOrDefault(a => a.Key == "param1");
string someAccess = dbContext.GetAccess(param, context.User.GetUserId());
bool authorized = SomeEvaluation(param, someAccess);
if (authorized) context.Succeed(requirement);
else context.Fail();
return Task.CompletedTask;
}
However, I wasn't able to motivate my choice (other than the guts and others' samples), so finally, I got unsure. I'm humble to understand that if I can't explain why, then maybe I'm wrong.
I googled claims based security and roles policies security etc. but I could come up with a name for the suggested alternative. Consequently, I haven't found any material discussing that matter.
What is such a custom authorization method called and what's the advantage/caveat of it?