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

[FASupportBot]

I'm using FusionAuth's event webhook system to track user login activity across multiple applications. I've noticed that user.login.success events with authenticationType set to certain values (e.g., refresh token grants or silent authentication flows) do not include an applicationId field in the event payload.

This creates problems for our use cases:

• Platform observability and analytics
• Data export pipelines that need to attribute logins to specific applications
• Customer support tooling that requires knowing which application a user authenticated to

Without the applicationId, I cannot deterministically derive which application the user authenticated to. Is this expected behavior? How can I reliably determine the originating application for all authentication types?

[FASupportBot]

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.