Ideas for improvements around Authentication / Authorization

[sissbruecker]

We are currently looking into how we could make Hilla React developers more productive with regards to implementing authentication and authorization in their applications. The following is a list of ideas from an internal workshop that we want to share for public discussion. Feel free to comment or share your own ideas.

Package auth features into the framework

Currently it is possible to generate a Hilla React starter with auth support that provides a lot of functionality that developers would expect. However, providing all of this in a starter is problematic, as the developer now owns this code even without applying customizations, and the code will not receive improvements or fixes that we apply later.

Instead we should provide these features as part of the framework and then make it easy to enable and configure those within an app. These features should include:

• A default Spring Security configuration
• An endpoint for retrieving information about the authenticated user
• An easy means to implement access control for client-side routes
• A React context and hook to access authentication state from within components

Those features should provide some means of customization, or should be replaceable with custom implementations when these means of customization are not sufficient.

Improve documentation

The current Security documentation for Hilla React provides little details how to actually set up authentication and authorization, or how to solve use-cases around it. Ideas on how to improve it were:

• It should explain how to set up auth, either using the default features or a custom implementation
• As Spring Security is the only integration that we have we should center the docs on that
• It should focus on use-cases that developers need to solve. For example:
  • How to access the authenticated user in an endpoint in order to pass it to a database query to make sure that a user only sees their own data.
  • Using the React auth context to implement a login form or a logout button
  • Using authentication state in the frontend to display the user name, or show / hide a button based on some role.

Leverage frontend and backend integration

Hilla has the advantage that frontend and backend are integrated within the same framework, which allows us to provide additional information to the frontend to make it easier to implement auth, as well as identify and debug issues with it.

Reuse authentication checks from the backend in the frontend
A common requirement is that an endpoint can only be accessed if the user has a certain role, which in Hilla is implemented as an annotation on the endpoint or an endpoint method:

  @RolesAllowed("ROLE_ADMIN")
  public void deleteUser() {
    ...
  }

Then in the frontend you might also want to enable/disable the corresponding button based on whether the user has that role:

const { hasRole } = useAuth();
...
<button disabled={!hasRole('ROLE_ADMIN')}>Delete user</button>

Instead of duplicating the permission check in the frontend, and risk them getting out of sync, we could investigate possibilities to just reuse the permission check that already exists in the backend. One idea was that instead of checking for roles, simply check whether the user is allowed to call a certain endpoint / method:

const { isAllowed } = useAuth();
...
<button disabled={!isAllowed(UserEndpoint.deleteUser)}>Delete user</button>

Provide helpful feedback when endpoint calls fail due to permissions

Currently, if an endpoint call fails due to permissions, you get an error logged to the browser console, which looks like any other error. Since Hilla knows which roles an endpoint method requires, we could provide some helpful feedback, such as:

• Identify the error as an authentication / authorization error
• List which roles the endpoint requires, and which roles the authenticated user actually has

Provide an overview of how all endpoints are secured

Currently it is not easy to get an overview if and how your endpoints are secured. You would have to go through several code files, check the annotations on the classes and individual methods. Since we have access to the endpoint classes in the backend, we could provide a UI in the dev tools UI that:

• Lists all registered endpoints
• Shows whether those require authentication or not
• Shows which roles have access to those

This UI could also expand into other feature areas such as quickly testing endpoints.

Other ideas

• Easy means to set up a default user during development so developers don't have to mess with Spring Security or databases to be able to see their UI
• Provide a dev tools UI that allows to change authentication state right from within the browser. This could be useful when implementing auth checks in the UI. Instead of having to create different test users with different roles, and having to log out and log in again, developers could just toggle roles or switch between profiles right from the dev tools in the browser to test their implementation.
• Provide a ready-made feature for sharing individual entities with other users, akin to Google Docs share links
• Provide social auth integration