During Sprint 3, I focused heavily on the backend authentication logic. My main task was to modify the codebase so that it could dynamically retrieve the correct public key used for JWT validation. This step was crucial for ensuring that our system could securely verify user tokens issued by Keycloak. Instead of hardcoding a single static key, the backend now pulls the current key from Keycloak’s endpoint and matches it using the kid field found in the JWT.
This task pushed me to explore how Keycloak exposes realm-level signing keys and how JWTs are structured. It also helped me better understand public key cryptography and secure token verification.
During Sprint 3, I focused on backend authentication endpoint logic by modifying the codebase to dynamically retrieve the correct public key for JWT validation. This task was essential to ensuring our system can securely verify user tokens issued by Keycloak. It challenged my understanding of authentication flows and pushed me to dive deeper into how Keycloak exposes realm keys.
Evidence of activity
Issue: modify backend to dynamically retrieve public key
Implemented logic within checkRole.js to call getPublicKey() and extract the appropriate key using the kid field from the JWT and matching it against the list of keys returned by Keycloak.
link: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/iamsystem/fake-backend/-/issues/4
What Didn’t Work Well:
One major blocker this sprint was that the endpoint wasn’t receiving a JWT token as expected. After some investigation, I suspect the issue is related to the backend not properly communicating with Keycloak, possibly failing to redirect or authenticate correctly before reaching the protected route. This made it difficult to fully test the dynamic key retrieval logic, and the issue is still unresolved as of the end of the sprint.
What Could Be Improved as a Team:
Our team could benefit from more consistent backend–frontend integration testing and clear documentation on authentication flow. It wasn’t always obvious where the token was supposed to come from or how to manually test the endpoint without the frontend completely wired up.
What I Could Improve as an Individual:
I want to improve my ability to troubleshoot backend services in containerized environments. I lost time trying to debug the issue without logging enough information or verifying network communication with Keycloak directly. Going forward, I’ll add more temporary logs and use tools like Postman or curl to manually test endpoints early in the process.
Apprenticeship Pattern: Breakable Toys
This pattern encourages building small, throwaway projects where it’s safe to fail, experiment, and learn without pressure.
Summary: Breakable Toys is about creating personal projects that mirror real world systems but are safe to break. These projects help you explore ideas, try new technologies, and learn from mistakes without real-world consequences.
Why I Chose It: During Sprint 3, I treated parts of our backend authentication system like a breakable toy. Since I wasn’t sure how Keycloak integration would work, I built a small test route to experiment with JWT decoding and key matching before applying the logic to the real project.
Behavior Change: This mindset helped me be less afraid to experiment. I now approach new problems by first building a quick, isolated version just to understand how things work, which makes me more confident when implementing the final solution.
From the blog The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.