问题
I have a web API service that allows a user to create a new resource like: POST /api/resource. The service then puts the creation request on a service bus and responds with HTTP 202 Accepted.
A background process picks up the message from service bus and calls the data access layer to create the resource. However, in order to enforce access control, the data access layer needs to know who the user is to determine whether he/she is allowed to create that resource. I cannot move this authorization logic into the front-end Web API and use a trusted subsystem for the data access layer.
So my solution is to get an access token for the data access layer and store it with the resource creation payload. But that presents a problem. As the message could be processed much later under heavy load, the token may have expired by the time the background process tries to use it. At that moment there is no way to renew the token either.
So I would like to loosen the requirements for the validity of tokens when handled in the backend tier. If the token is valid (trusted issuer etc) except that it is past the expiration time, I want the validation middleware to accept the token.
But there is no way to configure the System.IdentityModel.Tokens.Jwt token handler to validate expired tokens. Can this be done without writing my own token validator?
Is my approach wrong? What would be viable alternatives to solve this?
回答1:
the JWT handler has extensibility points that allow you to keep all the default validation logic and override only the aspect you want to customize - in this case the expiration validation. You can pass your own implementation of TokenValidationParameters.LifetimeValidator to achieve that.
回答2:
Look at using Refresh Tokens. Auth0 has a good article that explains the background and how they are used, with some sample code.
来源：https://stackoverflow.com/questions/35347055/validating-an-expired-jwt-token-behind-the-servicebus