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 containemail
field. But it does not. After logging in theapp.at
token looks like this:
Is this the correct behavior ? I mean, the e-mail is there in the
app.idt
along with other data:
Wouldn't it be better to change
app_at
toapp_idt
here to actually parse and verify ID Token instead of access token ?
-
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 andapp.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.
-
@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
-
@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
, andScope 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.
-