I'm currently working on implementing user authorization in my application, and I'm trying to decide between two approaches. I would appreciate some advice on the best practice for handling user authorization in a secure and efficient manner.
Communicating with API Endpoint: I'm considering implementing an authorization filter that communicates with the API endpoint to check user information required for authorization. This way, authorization decisions are always based on real-time data from the server.
Storing Data in Claims: Another approach I'm contemplating is storing relevant user data in the JWT claims and updating the token after the user completes the registration process. This would reduce the need for frequent API calls during user sessions.
Questions:
- What are the pros and cons of each approach?
- Are there security considerations I should be aware of for either method?
- How does each approach scale as the number of users and permissions grow?
- Are there any best practices or recommended patterns for handling user authorization in modern web applications?
Any insights or recommendations based on your experiences would be greatly appreciated. Thanks in advance!
This depends on how important it is to be able to make up-to-the-second decisions about authorization.
Usually, most security systems live with some degree of cached information. Back when I did Windows network operations in the late nineties, Windows Kerberos would issue a timestamped token with a list of IDs of all the security groups of which you were a member. This list would not change as long as you stayed logged in, so even if I as a network administrator changed your group membership, the change would only take effect the next time you logged on.
That's a long time ago, and it probably works differently today. I bring this up, however, to explain that issuing a token with authorization information is a tried-and-true architecture and is considered 'secure enough' for many purposes. (Keep in mind that security isn't an either/or question, but in reality a gradation where you trade functionality with security. The only absolutely secure system is one that doesn't exist.)
With modern token-based authorization (e.g. OAuth 2, which can contain claims) you can customize the expiration time. If you can live with authorization being cached for 20 minutes, but no longer, set the expiration to less than that (15 minutes?).
In the end, this is context-dependent, but I consider token-based authorization much simpler than having to call an API every time you want to do anything. Once you have the token, there are fewer moving parts, so fewer things may break.
Thus, unless liveliness is crucial, I'd lean towards claims-based authorization, but there are no best practices, only good architecture.