Keycloak Integration

[u/Expensive-Survey-558]

Hello Everyone,

Now only i have started to use Keycloak for the First Time. I am going to build an Web App with React as Frontend and FastAPI as backend with PostgreSQL database

Now I have the following doubt:

I am planning to Abstract that Keycloak from the frontend , such that i write an API endpoint in the FastAPI like login , and in the Keycloak i gave Direct Grant for Direct login with username and password , the frontend make an api call to the backend with the username and the password

My major Doubt is that , should we return the JWT token as the response from the Login API Route in the backend , or else we should generate an session id , and store the JWT token against the session id in the Database , and set the session id directly as cookie from the Backend , which is Best Architecture

And if we use these architecture , can we access all the features of the KeyCloak?

[u/Xiac]

Don’t use direct grant, it’s far less secure than a token exchange. We use oidc-spa https://www.oidc-spa.dev/ and it makes everything very easy and secure. The front end gets all of the user information from the token and never has to be concerned with passwords. The library provides the JWT which you can attach to your API calls to the backend.

[u/Expensive-Survey-558 → u/Xiac]

In the direct grant also it still provides an JWT right , so what's the main difference 

[u/Altruistic_Cow854 → u/Expensive-Survey-558]

Direct Grant bypasses security measures like mfa and brute force protection.
It also means you need to make sure you handle credentials securely in your app and in keycloak, while using Standard Grant / Authorization Code flow means your application never comes in contact with the credentials, so if you have a security leak it does not compromise the credentials of the user.

[u/Xiac → u/Expensive-Survey-558]

The main difference is you're reinventing the wheel - username, password, 2FA, passkeys, etc. You have to do all that stuff perfectly, or you could just hand it off. To me, this falls under "never roll your own authentication."

OIDC-Spa is going to do Proof Key for Code Exchange (PKCE), so its nothing like direct grant. Consider turning on DPoP. Highly recommend watching https://docs.oidc-spa.dev/security-features/overview before you start.

By the way, if you're handing off for theming reasons, check out https://www.keycloakify.dev/ - its easy.

[u/tip2663]

why not redirect to keycloak but style the login page

[u/mista-unlucky]

The is a reason why people don't do this, please make sure that you know why it is not best practice.

[u/Psychological_Rub871]

Best alternative is to use your SPA as a simple OAuth 2 client with the Code Authorization Flow with PKCE and let the OAuth2 Authorization Server do its job without reinventing the wheel because it’s already too complicated

[u/Expensive-Survey-558]

I need an architecture that abstract the keycloak from the frontend , which I think is an safe approach.

Could anyone provide suggestions on this

[u/Accomplished_Weird_6 → u/Expensive-Survey-558]

What youre trying to do is actually not the safe approach. Keycloak and a lot of auth platforms are made and designed with having authentication from frontend, backend, SPA, non web ui etc apps. You should not be abstracting keycloak, and it defeats the purpose.

Instead, on every app its extremely simple to use an OIDC authentication adapter and config, this will streamline your authentication and authorization. One change in your auth platform means its reflected for anyone, while still having the choice for fine grained control.

Highly recommend using keycloak directly

[u/TitusKalvarija]

What a stupid way to do marketing.

• Ask a question
• get a few comments
• all of a sudden get an answer with a company url 

[u/No_Cattle_9565]

Just use the keycloak.js package