oidc-client-ts
                                
                                
                                
                                    oidc-client-ts copied to clipboard
                            
                            
                            
                        MonitorSession always return "unchanged" status
Hi all,
Does anyone experience the situation that enables MonitorSession to true and always received "unchanged" status. Please correct me if i'm wrong. Here is my expectation.
- The admin login to IDP (Keycloak). Kick the use our by delete user's session.
 - The front-end application using oidc-client-ts and enable MonitorSession to true
 
I would expect the library would tell me that there is actually "changed" status so that the library can trigger silent login again. If the session already terminated in IDP (Keycloak) then login_required should be fired.
Regular login process happen.
My problem right now is the MonitorSession always return "unchanged" status so actually the application is waiting for token expired then it discovered that session is already terminated which is quite late.
According to specification: https://openid.net/specs/openid-connect-session-1_0.html the IDP or OP IFrame should immediately tell application or RP IFrame that there is something changed with the session and please trigger process for silent login to figure out.
In this case the KEYCLOAK_SESSION or IDP_SESSION value in the cookie keeps always the same. If I change this value manually in the browser then I get "changed" status and everything is working as expected. Because that's what is written in /protocol/openid-connect/login-status-iframe.html which is OP IFrame from IDP
Thanks a lot for your time. I really need help here.
@brockallen i follow your old repository to here. Any suggestion for me please ?
I am not using this the session monitor feature. But others do i guess.
- You can add logging (https://authts.github.io/oidc-client-ts/#logging) to get more insights.
 - You can verify what data you receive from the IDP
 
probably fixed with v3.0.0-beta.0
Has this problem been solved now?