How to Handle Stale Sessions in a Spring Token Mediating Server with Keycloak Authorization?

Getting advice
1

I am working on a Spring-based token mediating server with Keycloak as the authorization server.
Upon successful login, I receive a session ID, access token, and refresh token.
I save the session ID and refresh token in my token mediating server.

Here’s how my system works:

The frontend calls the session API with the session ID in a cookie.
The token mediating server uses the refresh token to generate a new access token and returns it to the frontend.
If the session expires in Keycloak, my token mediating server doesn’t know because it relies on its database for session IDs.
To address this, I implemented a check to verify the session status in Keycloak whenever I reference my session ID table.
This ensures that sessions are cleared from both the browser and the token mediating server database if they are no longer valid in Keycloak.

However, I face an issue where the session ID might be lost in the browser (e.g., due to clearing cookies or using incognito mode).
This leaves stale sessions in my database, although Keycloak eventually removes them.

I have a scheduler to periodically clear stale sessions from the token mediating server database if they are no longer in Keycloak.

My questions are:

Is it the right approach to keep session checks in both Keycloak and my database?
If I want to remove the table storing refresh tokens, how should I handle generating new tokens?
If I am not using refresh tokens, is re-initiating the login flow the right approach?

Any advice or best practices for managing sessions and tokens in this setup would be greatly appreciated. Thank you!

2

Just review OAuth 2.0 for Browser-Based Applications [1], as there are some BFF BCP.

In relation to your latest question, if you are not using RT, the only way to get new tokens is by going back to the IdP, and it will return new tokens if the IdP cookie is still valid.

Lastly, try not to overcomplicate things, if you do, you may end up maintaining a “Frankenstein.”

[1] draft-ietf-oauth-browser-based-apps-18

3

BCP structure is more vulnerable , Is there any other way I can Handle RT

4

That affirmation makes no sense

2 Likes
5

In BCP fronth-end will get access , refresh token which is vulnerable right?

6

Did you ever read what @embesozzi has linked?
In this document, there are ways described, which prevents you from being vulnerable (or, let’s say, being less vulnerable), like e.g. the BFF approach.

1 Like
7

I have built the code referring to that article. Currently, I won’t be able to use BFF as it requires a huge architectural change. I am using a TMS (Token Mediating Server).

However, my main question is different. Should I maintain a copy of session details in the Token Mediating Server? I am currently maintaining this for the sake of the refresh token. If there was a way to get the refresh token directly from Keycloak using session id or something, I wouldn’t need to maintain an extra table in the Token Mediating Server.