<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Why do user.login.success events lack applicationId for certain authentication types?]]></title><description><![CDATA[<p dir="auto">I'm using FusionAuth's event webhook system to track user login activity across multiple applications. I've noticed that <code>user.login.success</code> events with <code>authenticationType</code> set to certain values (e.g., refresh token grants or silent authentication flows) do not include an <code>applicationId</code> field in the event payload.</p>
<p dir="auto">This creates problems for our use cases:</p>
<ul>
<li>Platform observability and analytics</li>
<li>Data export pipelines that need to attribute logins to specific applications</li>
<li>Customer support tooling that requires knowing which application a user authenticated to</li>
</ul>
<p dir="auto">Without the <code>applicationId</code>, 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?</p>
]]></description><link>https://fusionauth.io/community/forum/topic/3206/why-do-user-login-success-events-lack-applicationid-for-certain-authentication-types</link><generator>RSS for Node</generator><lastBuildDate>Sun, 04 Oct 2026 23:45:26 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/topic/3206.rss" rel="self" type="application/rss+xml"/><pubDate>Fri, 02 Oct 2026 23:55:40 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Why do user.login.success events lack applicationId for certain authentication types? on Fri, 02 Oct 2026 23:55:51 GMT]]></title><description><![CDATA[<p dir="auto">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 <code>applicationId</code> because the authentication isn't directly tied to a specific application registration at that moment.</p>
<h2>Workarounds and Best Practices</h2>
<h3>1. Check the JWT for Application Context</h3>
<p dir="auto">Your applications should be validating the JWT claims after authentication, including:</p>
<ul>
<li><code>applicationId</code> (or <code>aud</code> claim) — identifies which application the token was issued for</li>
<li>Other application-specific claims</li>
</ul>
<p dir="auto">See <a href="https://fusionauth.io/articles/tokens/jwt-components-explained" rel="nofollow ugc">JWT Components Explained</a> for details on these claims.</p>
<h3>2. Enable Automatic Registration on Proxy Applications</h3>
<p dir="auto">If you're using a proxy or gateway application that performs authentication on behalf of other applications, enable <strong>automatic registration</strong> for that proxy application. This ensures users are properly registered to the proxy app, which can help maintain application context.</p>
<p dir="auto">Refer to the <a href="https://fusionauth.io/docs/get-started/use-cases/app-suite#edge-cases" rel="nofollow ugc">Application Suite edge cases documentation</a> for scenarios where this pattern is useful.</p>
<h3>3. Alternative Event Sources</h3>
<p dir="auto">For complete application attribution, consider:</p>
<ul>
<li>Using <code>user.registration.create</code> events when users first register to applications</li>
<li>Combining <code>user.login.success</code> events with application-level audit logs</li>
<li>Implementing custom event enrichment in your webhook consumer that correlates login events with subsequent token validation</li>
</ul>
<h2>Important Note</h2>
<p dir="auto">Self-service registration, if enabled, allows anyone to register to that application. Your applications should always validate that the user has a proper registration (<code>jwt.applicationId</code>) and any other business-specific claims required for access.</p>
]]></description><link>https://fusionauth.io/community/forum/post/8749</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/8749</guid><dc:creator><![CDATA[FASupportBot]]></dc:creator><pubDate>Fri, 02 Oct 2026 23:55:51 GMT</pubDate></item></channel></rss>