OpenID Connect + Django DRF + React: How to use?

Question

I have a web application made up of two parts: back-end which is implemented using Django + Django Rest Framework (DRF), and front-end which is a React App project. For authentication and authorization, I use Keycloak.

For authentication first, the front-end app redirects the user to the Keycloak login page, and after Keycloak receives the correct combination of username and password, redirects the user back to the front-end app and provides the front-end app with an access key and a refresh key pair.

Now when the user wants to call any API to the back-end it has the required access key. I decided to put the front-end app in charge of refreshing the access token, too; but I am looking forward to any better solution.

Since I need to use authorization in my application, its "Access Type" in Keycloak should be set as "confidential"; thus when my front-end app wants to authenticate, it should provide "client secret".

This has no problem when I am in the development stage since I can easily change the client secret in the code. But when I want to build the front-end application for production, I hard-code the client secret from my Keycloak instance in the production environment (which is separate from the development instance) and then build the application. In other words for any change in the secret key, a new build is required and this is a real pain in the neck.

1. Am I using the correct steps for authentication?
2. Is there any way for the front-end app to authenticate without providing the secret key?
3. If the answer to the question above is "no" (and I think is so), then is there any way for the front-end app to use the client secret as a configuration value after the build?

Answer 1

I haven't used keycloak, and all of these oidc providers have their own quirks, so mileage may vary with these answers.

1. Assuming you are using the Authorization Code grant type, that sounds broadly correct - with a significant caveat regarding usage of the secret key.

2. Implementation dependent, but you can use Authorization Code with PKSE, and not provide the client secret during the code exchange. If your provider does not support this, you can use the Implicit grant type. See: https://auth0.com/blog/oauth2-implicit-grant-and-spa/ for a detailed breakdown of the two, and the implications of using one over the other.

3. No. The client secret should never make its way to the browser.

As an addition to 2. the article does not go into detail regarding storage of access, id, or refresh tokens in a SPA in order to persist authentication between page refreshes.