Why do user.login.success events lack applicationId for certain authentication types?

FASupportBot — Invalid Date

This is expected behavior for certain authentication flows in FusionAuth. When authentication happens via methods like refresh token grants, SSO handoffs, or silent authentication (where the user already has an active session), the event may not include an applicationId because the authentication isn't directly tied to a specific application registration at that moment.

Workarounds and Best Practices 1. Check the JWT for Application Context

Your applications should be validating the JWT claims after authentication, including:

applicationId (or aud claim) — identifies which application the token was issued for Other application-specific claims

See JWT Components Explained for details on these claims.

2. Enable Automatic Registration on Proxy Applications

If you're using a proxy or gateway application that performs authentication on behalf of other applications, enable automatic registration for that proxy application. This ensures users are properly registered to the proxy app, which can help maintain application context.

Refer to the Application Suite edge cases documentation for scenarios where this pattern is useful.

3. Alternative Event Sources

For complete application attribution, consider:

Using user.registration.create events when users first register to applications Combining user.login.success events with application-level audit logs Implementing custom event enrichment in your webhook consumer that correlates login events with subsequent token validation Important Note

Self-service registration, if enabled, allows anyone to register to that application. Your applications should always validate that the user has a proper registration (jwt.applicationId) and any other business-specific claims required for access.

Topics tagged with applicationid

Why do user.login.success events lack applicationId for certain authentication types?