No other event than "KeycloakEventType.Ready" dispatched

[somq]

Not sure if I'm doing something wrong but I cannot get any other event than KeycloakEventType.Ready ({type: 'Ready', args: true}).

Following this example, I expect, for instance, to see AuthLogout and AuthSuccess events getting dispatched on logout/login to raise an explicit isConnecting flag.

Bug Report or Feature Request (mark with an x)

- [x ] bug report 

Versions.

• Keycloak: v19.0.2
• Angular 19

Repro steps.

The standalone example reproduces this behavior.

The log given by the failure.

Only KeycloakEventType.Ready ({type: 'Ready', args: true}) is dispatched.

Desired functionality.

It should report all states in KeycloakEventType enum.

[sergiunagy]

I'm using the something like the following snippet to understand the sequence: effect(()=>{ const evt = this.#keycloakStatus(); console.log([AUTHSRV] ${new Date().getTime()} -- ${evt.type}-- ${JSON.stringify(this.#client)} ); ...

I'm then running a simple login on the keycloak client which successfully executes a sign in. I saw the follwoing events so far. On sign in : KeycloakEventType.Ready , KeycloakAngularInit

On refresh , I caught the following: TokenExpired, AuthRefreshSuccess

On Logout: KeycloakEventType.Ready , KeycloakAngularInit

The issue seems to be that some events are lost during the context switch between initial page load (app server) , sign in page (Keycloak server) then back to page load (app server) which also re-runs initialization. Reload also happens on Logout so that signal state is also missed.

On sign in, keycloak will cache the state on the local browser and on the 2nd init it finds and loads it from there, basically authenticating the user.

I'm currently detecting the Ready state, then inspecting the authenticated status. I'm not sure this is the intended way of using it though :)

[jdussouillez]

Same issue here, I'm logging all events and I'm getting only Ready even when I log out, refresh token, etc.

[tjulioh]

Same issue here

+1 here

[harbard75]

Yep, same here. KeycloakEventType.AuthSuccess and KeycloakEventType.AuthLogout are not triggered at all

[fcelarino]

Same issue here. Any chance to get it prioritized because it blocks any auth flow

[fguiet]

Hi,

Same issue here.

Here is the code I am using.

KeycloakEventType.Ready is triggering but AuthSuccess is not

import { effect, inject, Injectable, InjectionToken, Signal } from '@angular/core';
import Keycloak from 'keycloak-js';
import { UserProfile } from '../components/models/userprofile.models';
import { KEYCLOAK_EVENT_SIGNAL, KeycloakEventType } from 'keycloak-angular';

@Injectable({
  providedIn: 'root'
})

export class AuthService {

  userProfile: UserProfile | undefined
  private readonly keycloakSignal = inject(KEYCLOAK_EVENT_SIGNAL);

  constructor(private readonly keycloak: Keycloak) {
    console.log('AuthService initialized');
    keycloak.onAuthSuccess = () => console.log('Authenticated!');

    effect(() => {
      const keycloakEvent = this.keycloakSignal();
      
      if (keycloakEvent.type === KeycloakEventType.AuthSuccess) {
        console.log('Keycloak authenticated');
      }

      if (keycloakEvent.type === KeycloakEventType.Ready) {
        console.log('Keycloak init ok');
      }
      
    });
  }

[thelongshot]

I'm coming across the same issue, and I wonder if the issue is that the signal is being injected after authentication, which is why we don't get AuthSuccess. It seems one of the downsides of signals is that we don't get replay capability like in rxjs.

[erikm-of]

I believe signals might not be the best option here as these are events and not states. What if two keycloak events emit at almost the same time, it can theoretically happen that the signal never gets the first of the two values and immediately calculates the last state (as signals are suppose to be glitch free). I don't believe that is the issue in this case, but still...

edit: After some debugging, I believe I've at least seen a situation where the AuthSuccess event is never received, because it is immediately overwritten with Ready.