<?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[Topics tagged with 1-70-0]]></title><description><![CDATA[A list of topics that have been tagged with 1-70-0]]></description><link>https://fusionauth.io/community/forum/tags/1-70-0</link><generator>RSS for Node</generator><lastBuildDate>Thu, 12 Nov 2026 13:27:46 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/tags/1-70-0.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Why is &#96;act&#96; claim now reserved in 1.70.0? Lambda silently fails with no warning]]></title><description><![CDATA[<p dir="auto">The act claim was reserved in FusionAuth 1.70.0 because it is defined in <a href="https://datatracker.ietf.org/doc/html/rfc8693#section-4.1" rel="nofollow ugc">RFC 8693 (OAuth 2.0 Token Exchange)</a> as a standard claim representing the "actor" in delegated token scenarios. FusionAuth began enforcing this reservation to ensure compliance with the RFC and prevent conflicts with the claim's intended usage in token exchange flows.</p>
Why This Is Classified as Minor
<p dir="auto">FusionAuth follows semantic versioning, and this change was classified as minor rather than breaking because:</p>

The act claim is a <strong>standardized RFC claim</strong> with a specific defined purpose
Using non-standard values in RFC-defined claims can cause interoperability issues with other OAuth/OIDC systems
The change aligns FusionAuth's behavior with industry standards

<p dir="auto">However, the lack of logging when a reserved claim is silently discarded is a valid concern and makes troubleshooting difficult.</p>
Recommended Solutions
1. Use a Custom Claim Namespace
<p dir="auto">Instead of using act directly, use a namespaced custom claim that won't conflict with RFC-defined claims:</p>
// In your JWT populate lambda
jwt['https://yourapp.com/actor'] = 'your-actor-id';

<p dir="auto">This approach is standard practice in OAuth/OIDC and prevents future collisions with reserved claims.</p>
2. Use applicationId or Other Non-Reserved Claims
<p dir="auto">If the actor represents an application or service account, consider using the built-in applicationId claim or another custom claim that describes your specific use case (e.g., actorId, serviceAccountId).</p>
Why Reserved Claims Cannot Be Overridden
<p dir="auto">Reserved claims like act, sub, iss, aud, etc., are protected because they have specific meanings defined by RFCs and must maintain consistent behavior for:</p>

<strong>Interoperability</strong>: Other systems expect these claims to have specific formats and meanings
<strong>Security</strong>: Claims like iss and aud are critical for token validation and cannot be arbitrarily changed
<strong>Standards Compliance</strong>: FusionAuth aims to be a standards-compliant identity provider

Migration Path
<p dir="auto">If you're currently using act in production:</p>

Update your JWT populate lambda to use a namespaced custom claim
Update your application to read from the new claim name
Test thoroughly in a non-production environment before upgrading

<p dir="auto">If you need to maintain backward compatibility during migration, you could temporarily set both claims in your lambda (the custom namespaced one and attempt to set act, knowing it will be discarded) and update your application to check for both, prioritizing the custom claim.</p>

Related Documentation

<a href="https://fusionauth.io/docs/lambdas/tokens/jwt-populate" rel="nofollow ugc">JWT Populate Lambda</a> - Documentation on customizing JWT claims with lambdas
<a href="https://fusionauth.io/docs/lambdas/tokens/client-credentials-jwt-populate" rel="nofollow ugc">Client Credentials JWT Populate Lambda</a> - Documentation for lambdas in the Client Credentials grant
<a href="https://fusionauth.io/docs/authorization/token-exchange" rel="nofollow ugc">OAuth Token Exchange (RFC 8693)</a> - FusionAuth's implementation of RFC 8693, which defines the act claim
<a href="https://fusionauth.io/docs/release-notes#version-1-70-0" rel="nofollow ugc">FusionAuth 1.70.0 Release Notes</a> - Release notes for version 1.70.0
<a href="https://fusionauth.io/blog/announcing-fusionauth-1-70" rel="nofollow ugc">FusionAuth 1.70 Announcement: Token Exchange</a> - Blog post explaining the new token exchange feature and scoped delegation
<a href="https://github.com/FusionAuth/fusionauth-issues/issues/1721" rel="nofollow ugc">GitHub Issue #1721: JWT claim overriding, namespacing or the ability to unreserve claims</a> - Open issue discussing the ability to override or unreserve claims

Additional Context on Reserved Claims
<p dir="auto">As of FusionAuth 1.70.0, the following claims are reserved in <strong>JWT Populate Lambdas</strong> and cannot be modified:</p>

act (added in 1.70.0)
amr
auth_time
authenticationType
cnf
fa_uid
gty
iat
sub
tid
tty

<p dir="auto">Note: The exp claim can be <strong>lowered</strong> (shortened) but not extended or removed.</p>
<p dir="auto">For other lambda types (Client Credentials, UserInfo, Token Exchange), different sets of reserved claims apply. Always use namespaced custom claims (e.g., https://example.com/my-claim) to avoid conflicts with current or future reserved claims.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/3357/why-is-act-claim-now-reserved-in-1-70-0-lambda-silently-fails-with-no-warning</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3357/why-is-act-claim-now-reserved-in-1-70-0-lambda-silently-fails-with-no-warning</guid><dc:creator><![CDATA[FASupportBot]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>