Thoughts on JWT enhancements - add to framework or as separate module?

[W6HBR]

The current JWT solution only allows long-lived JWT for administrators. I have the need to issue long-lived tokens for normal logins as well and as such I’ve had to modify the default behavior. This need stems from a requirement to allow 3rd parties access to specific module API endpoints without being a full administrator. E.g. for my use, this allows 3rd parties to use the API to query product information as a normal user of the module (read only) without full administrative rights. They need the ability to have a long-lived token so their integrations would only need to be updated once a year with a new credential.

As implemented, I have modified the following:
(1) “User Profile” \Oqtane.Client\Modules\Admin\UserProfile\Index.razor

• Added fields & button to user Identity section to allow generation and display of token
• Added function to call UserService.GetPersonalAccessTokenAsync() for issuance of token.
• This functionality mirrors the fields and functionality already present in “User Management” \Oqtane.Client\Modules\Admin\Users\Index.razor

(2) \Oqtane.Server\Controllers\UserController.cs

• Changed “personalaccesstoken” API to allow “Registered” userrole access instead of limiting to “Admin” userrole.

The changes above have met my immediate needs, but I’m now looking at making changes to manage and revoke tokens as well as controlling which users could access this feature. Currently, there is no way to revoke a token (that I know of). The only real option appears to be changing the site secret which would invalidate ALL tokens.

Some ideas I’m thinking of:

• Admin controlled setting in Identity section of “User Management” to allow Admins to choose which users can make use of long-lived tokens.
• Store a checksum/hash of a generated long-lived token in the settings table for each user.
• Check token when used (JwtMiddleware.cs) to see if the checksum matches and if not, consider the token revoked.
• Allow single JWT per user or manage multiple tokens?
• Allow users to self-service issuance of tokens or have Admin issue for them?

I’m looking for feedback on the approach I’m thinking of. Also, the big question here is whether this is something that would be beneficial to be added to the Oqtane framework or should I just handle this for my needs as a new module?

[sbwalker]

I am curious why you would not use an external identity server?

[W6HBR]

That's another layer for the client to manage. They don't need it and it makes it easier to manage access to the website from the website.

I'm also not seeing how using an identity server would allow revoking tokens on an individual basis - at least not in Oqtane. It would all have to be done in the external identity server.

[sbwalker]

The reason I asked is because you essentially want an OAuth Client Credentials Flow, and most Identity Servers provide this functionality - and they provide it in a way which is consistent with the OAuth specification (including revoking tokens, etc...).

I can totally understand the desire to not want to manage another piece of infrastructure as it requires additional configuration and cost. But I would be hesitant to try to roll my own implementation.

If it can be done in a way which aligns with security best practices then it may be worth exploring as an Oqtane framework enhancement.

[sbwalker]

@W6HBR One thing which I should mention... if you take a look at Oqtane's Jwt token middleware class (Oqtane.Server\Infrastructure\Middleware\JwtMiddleware.cs) you will see that it validates the token it receives, extracts some basic claims (userid, username), and then reloads the roles for the user before creating the claims principal.

Basically this means that Oqtane does not rely on the role claims in the token itself ie. as they may have changed since the token was issued. So you do not need to worry about revoking a token - you simply need to remove the roles for a user from within Oqtane and the next time that user tries to access an API using the token, the system will retrieve their current roles and prevent them from accessing the method.

Please note that this is only true for tokens processed by Oqtane's middleware. If you issue a long-lived token and send it to a remote API, the best it can do is validate the token - however it will need to rely on the list of role claims contained within the token (as it has no way to refresh them). This explains why long-lived tokens are a security risk - but it sounds like you are not using this remote scenario so you should be able to rely on Oqtane's middleware.

Note that Oqtane also has the ability to issue a short-lived token. Short-lived tokens are considered to be more secure as they have a limited lifetime. Your external client can call the UserController /token endpoint to get a short-lived token (which is available to registered users) - and then use that token to call other APIs. This is the general approach I have seen recommended as opposed to generating long-lived tokens and storing them in the client.