<?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 access tokens]]></title><description><![CDATA[A list of topics that have been tagged with access tokens]]></description><link>https://fusionauth.io/community/forum/tags/access tokens</link><generator>RSS for Node</generator><lastBuildDate>Sun, 07 Jun 2026 19:25:55 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/tags/access tokens.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Token type?]]></title><description><![CDATA[<p dir="auto">Seems like the library I used is opinionated. Thanks for the hints.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/433/token-type</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/433/token-type</guid><dc:creator><![CDATA[AliMirlou]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Are FusionAuth access tokens always JWTs?]]></title><description><![CDATA[<p dir="auto">Yes. While OAuth2 access tokens aren't guaranteed by the spec to be JSON web tokens, in FusionAuth <a href="https://fusionauth.io/community/forum/topic/426/when-is-introspect-endpoint-needed/4">access tokens are always JWTs</a>.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/430/are-fusionauth-access-tokens-always-jwts</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/430/are-fusionauth-access-tokens-always-jwts</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Can we add more information to the access token response we get during the OAuth flow?]]></title><description><![CDATA[<p dir="auto">That response is essentially defined by OAuth2 / OIDC as the token response. If you want to customize it, the best solution is to use a lambda to encode additional details in the access_token (JWT) and then at the client decode that value to extract the necessary claims.</p>
<p dir="auto">More on lambdas: <a href="https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate" rel="nofollow ugc">https://fusionauth.io/docs/v1/tech/lambdas/jwt-populate</a></p>
]]></description><link>https://fusionauth.io/community/forum/topic/123/can-we-add-more-information-to-the-access-token-response-we-get-during-the-oauth-flow</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/123/can-we-add-more-information-to-the-access-token-response-we-get-during-the-oauth-flow</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[How should I validate access tokens?]]></title><description><![CDATA[<p dir="auto">There are a few things to consider.</p>

how long tokens live for
what happens if permisssion are modified in FusionAuth but the protected resource still allows access?
any performance worries due to a large number of accessToken validation calls being made by the protected resource.

<p dir="auto">With the first approach (validating the access token without communicating with FusionAuth) the holder of the token will be able to access your API as long as the token is valid (unless the API server communicates periodically with FusionAuth to check the validity). In addition, changes to user privileges won't take place until the JWT expires and the client retrieves a new access token using the refresh token.</p>
<p dir="auto">With the second approach, if a token is revoked in FusionAuth (if for instance the user is disabled) the access is cut off immediately. The cost is that you're making an additional network call every time, which has a performance impact. Note that if you could use the userinfo endpoint instead of the token if you want updated user claims. The token endpoint isn't going to give you that information, just a yes/no depending on if the token is valid.</p>
<p dir="auto">So it's hard to make a recommendation without knowing what the consequences of unauthorized access to your API or protected resource would be. It also would be helpful to know the expected traffic; if it is expected to be low, the performance impact of the second approach will be minimal.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/49/how-should-i-validate-access-tokens</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/49/how-should-i-validate-access-tokens</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>