I’m looking for some guidance/ideas on how I should integrate Keycloak login and auth in an application where we have a mixture of both legacy and “modern” components.
The application server is built in a fairly traditional PHP MVC way, typically using form posts instead of REST calls to do work, and using cookies and sessions to handle auth server-side. However some components are now starting to be built in React, these are dynamically mounted client-side once the page has loaded, these purely interact with a shiny new GraphQL API which exists as a microservice, rather than calling any PHP-land endpoints.
So it seems two different clients are needed, I have the frontend login working with keycloak-js and I receive a token in JavaScript. But now the backend needs credentials.
Should I set up an endpoint on the PHP server to send it the token from the frontend? Then PHP can store the token in the session and verify that against
Or should I reverse the way the client works and have PHP server receive the callback URL from keycloak, verify the auth, and then pass a token to the frontend which I can insert into the keycloak client.
Just going a little bit in circles trying to figure out how this is supposed to work. Has anyone dealt with a similar setup? Many thanks
Why not just pass requests to the backend with the token in the header? E.g.
Authorization: Bearer <token>
You can have two clients, one for frontend and backend, perhaps both with different scopes, etc. But you only need to authenticate once, and then you can use the token in both places to validate the user’s identity.
You can’t set headers when using an old-school POST. You have to rely on cookies.
For now I need to mimic the legacy system otherwise we basically have to rewrite the entire app and that’s a several month roadmap. Those areas will end up getting rewritten eventually when the new design is ready and eventually everything will be using jwt and API calls.
But basically I am suggesting a similar principle, I will just do a single call to send the client id and client secret to the backend, the backend can store those in session and use them to validate itself against keycloak. Then they don’t need to be in headers in every request.
Can you set a cookie on the front end with the access token value? Keycloak does this with the ID token as KEYCLOAK_IDENTITY, but I don’t think the access token is present as a cookie.
The problem with the approach you’re suggesting is that you won’t have a client id/secret per user, and sending that isn’t going to give the identity of the user.
Also, default access token lifespans are short (by design), and storing in the session is not a good idea, as you’ll have a stale access token almost immediately.
If you could diagram out your current “legacy” request cycle and how you intend to make requests, it might help us give better suggestions.
I am not really sure how to diagram the legacy requests. It’s a website sending HTTP POST requests using a form element to a PHP backend and receiving HTML pages in response. How is keycloak auth normally integrated with a session-based backend?