<![CDATA[E-mail field not exists in access token]]>According to the docs here:
https://fusionauth.io/docs/quickstarts/quickstart-php-laravel-api#provisioning-new-users
the access token received from the FusionAuth should contain email field. But it does not. After logging in the app.at token looks like this:
96b5500b-7749-4773-8c8d-1382e6b5e12f-image.png

Is this the correct behavior ? I mean, the e-mail is there in the app.idt along with other data:
1ecc59bb-91dd-43cf-8a4a-0b27df590ebf-image.png

Wouldn't it be better to change app_at to app_idt here to actually parse and verify ID Token instead of access token ?
c8f552b6-3cf0-45ea-8d75-1230182dd642-image.png

]]>https://fusionauth.io/community/forum/topic/2692/e-mail-field-not-exists-in-access-tokenRSS for NodeMon, 17 Aug 2026 05:23:26 GMTMon, 27 May 2024 08:37:29 GMT60<![CDATA[Reply to E-mail field not exists in access token on Tue, 28 May 2024 14:59:20 GMT]]>You can read more about the differences of the cookies set in our hosted backend documentation.

Cookies Set By the Hosted Backend

Name HttpOnly Description
app.at true The access token for the configured application. This is a JWT and can be presented to your APIs to access data and functionality.
app.rt true The refresh token for the configured application. Only present if the offline_access scope is requested. This can be presented to FusionAuth to retrieve a new access token.
app.idt false The Id token for the user for the configured application. Only present if the openid scope is requested. This is a JWT and can be accessed by JavaScript to display user account information.
app.at_exp false The unix epoch timestamp indicating when the access token will expire. This can be checked by JavaScript to determine when a refresh token should be used to get a new access token.

As you have called out the two tokens are meant for two different purposes.app.idt is available to the browser using JavaScript and app.idt is available only on calls that involve the server.

During true OAuth (not utilizing openid) you will not see email utilized. This is still valid for checking if a user is authenticated. You can send this to all of your API endpoints as well.

]]>https://fusionauth.io/community/forum/post/7309https://fusionauth.io/community/forum/post/7309Tue, 28 May 2024 14:59:20 GMT<![CDATA[Reply to E-mail field not exists in access token on Fri, 14 Jun 2024 14:40:46 GMT]]>@zaalbarxx sorry for the delay. I might be missing it (sorry not a PHP person) but I don't see where that confusion comes into play. I know that some of our docs had to get updated because of a change that we made during our 1.50 release that required to request further details in our scopes request.

This release makes significant changes to the default behavior of new Applications with regard to scopes in OAuth workflows. The database migration will update existing Applications to behave in a backwards compatible manner. See the OAuth Scopes documentation for more information, in particular the Relationship, Unknown scope policy, and Scope handling policy configurations.

https://fusionauth.io/docs/release-notes/#version-1-50-0

Let me know if that still isn't making sense, or if there is a spot you were hung up on and I would be happy to update our docs. Or even better feel free to add a PR.

]]>https://fusionauth.io/community/forum/post/7342https://fusionauth.io/community/forum/post/7342Fri, 14 Jun 2024 14:40:46 GMT<![CDATA[Reply to E-mail field not exists in access token on Wed, 29 May 2024 09:02:05 GMT]]>@Alex-Patterson Then I believe you should update your example repo, because the code there mistakenly makes reader think that the email will be there. Anyway, thanks for clarification, cheers 🙂

]]>https://fusionauth.io/community/forum/post/7318https://fusionauth.io/community/forum/post/7318Wed, 29 May 2024 09:02:05 GMT<![CDATA[Reply to E-mail field not exists in access token on Tue, 28 May 2024 14:59:20 GMT]]>You can read more about the differences of the cookies set in our hosted backend documentation.

Cookies Set By the Hosted Backend

Name HttpOnly Description
app.at true The access token for the configured application. This is a JWT and can be presented to your APIs to access data and functionality.
app.rt true The refresh token for the configured application. Only present if the offline_access scope is requested. This can be presented to FusionAuth to retrieve a new access token.
app.idt false The Id token for the user for the configured application. Only present if the openid scope is requested. This is a JWT and can be accessed by JavaScript to display user account information.
app.at_exp false The unix epoch timestamp indicating when the access token will expire. This can be checked by JavaScript to determine when a refresh token should be used to get a new access token.

As you have called out the two tokens are meant for two different purposes.app.idt is available to the browser using JavaScript and app.idt is available only on calls that involve the server.

During true OAuth (not utilizing openid) you will not see email utilized. This is still valid for checking if a user is authenticated. You can send this to all of your API endpoints as well.

]]>https://fusionauth.io/community/forum/post/7309https://fusionauth.io/community/forum/post/7309Tue, 28 May 2024 14:59:20 GMT