The frontend needs to performs the following steps to authenticate the user:
- Load the Keycloak lib and client configuration
- If the init is correct and the user is not authenticated, the Keycloak will redirect the browser to the Keycloak server login screen for her to be authenticated and then redirect back here properly authenticated.
- Else if the init is correct and at that point the user is authenticated, we provide a lambda that is called back calling the “loadUserInfo” function against the keycloak server
The following schema describes the steps and the interactions between the browser, the keycloak server and the API server:
Here are the code for each of those steps (in security.cljs):
At that point the user is authenticated with a token and its info is loaded, the rest is traditionnal re-frame machinery to dispatch the event, update the DB and so on.
Now that we get a token, we need to store it and be able to send it to the backend later on. We have different options for local storage, but mainly two for sending it to the backend: Cookie or HTTP Header. The Cookie option implies that we store it in the cookie store, with the header option we can do whatever we want. Just be aware that the token is quite secured and is nevertheless short-lived, so in case the token is accessed by rogue hands it should not be a major worry, we can also do both. Have a look at the code in “cookie.cljs”
Now the token we get back from the initial authentication process needs to be refreshed regularly. To do that, we setup a “ticker” mechanism that triggers regularly the refresh check and performs it when needed. I won’t enter into the details of re-frame event and effect handling, you’ll get plenty of top-notch documentation from the re-frame repo for that. Just have a look at the code in “interval.cljs”.