Keycloak-Remix integration: where should I place the checks?

I'm looking into Remix, and I would like to have authentication with Keycloak, an oauth authentication server. Most examples I find online don't use an external auth server with Remix, and the few people mentioning doing this have not provided examples.

I just have the initial notes application that comes as default with the create-remix command. I would like if possible to replace the default authentication with my external auth server, as a proof of concept. In my ideal scenario, the backend redirects the user to the Keycloak auth page, and once we receive a token, the backend shares the returned token with the front-end, as it loads the first bits of the app. This gets saved in the browser so that the user is authenticated. Then I have doubts on how the refresh token cycle and logout would work, but this is not my main concern now.

So, even if in theory it looks like Remix could perfectly implement a BFF proxy pattern (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-backend-for-frontend-bff-pr) I still don't understand what files are the concern of the backend and the front-end, and I don't trust I can implement this architecture safely without understanding where each bit of code is being run.

What I would like is ideally to see a working example, if not, any explanation that might come closest to that

In case is helpful for context, keycloack provides a js package to facilitate doing the requiered calls, I just don't know where to place them in remix

In the end I created my own implementation using openid-client.

In /routes I created routes for login, logout and callback.

• Login: redirects the user to the Keycloak auth URL. Keycloak will display the login page where the user needs to put their user and password, and then Keycloak will redirect to the /callback route along with the code and other params.
• Callback: This exchanges the auth code for the token set, saves whatever data needs to be saved by the application backend, and then creates the browser cookie and the user is redirected to whatever URL they were original trying to access with the session cookie in the header of the request.
• Logout: removes the local user session cookie and calls Keycloak's end session endpoint.

Most of the functions accessed in these pages live inside the folder src/utils, in a Keycloak Auth class that handles the interactions with openid-client. It sets up the client, visits the well-known endpoint, and has methods to access all endpoints I need.

There are also methods for refreshing the tokens and for exchanging the tokens between different Keycloak clients