@Alex-Patterson
Indeed, you are right, it is because of the scope configuration, whose default values have changed. The advice in the release notes regarding this in version 1.50 also sounds appropriate in retrospect.
What surprises me is that these settings are relevant when I perform the oldschool login via POST /api/login, I wasn't aware of that...
Thanks for the tip!
I would probably have been looking for the difference for a while...
I have the same problem (since my update from 1.51.X to 1.53.2 maybe?), but only for users created with the new version. This is strange...
The email claim is then missing in the token:
{
“aud": ‘fe6b5ed0-89a5-43f8-a7af-ec69c47a0c25’,
“exp": 1726866934,
“iat": 1726863334,
“iss": ‘xyz’,
“sub": ‘c1593867-dd98-4273-b965-8a15b101fbf8’,
“jti": ‘83b5bd18-2f3e-4c9e-91b6-2f5c8e49846b’,
“authenticationType": ‘PASSWORDLESS’,
“applicationId": ‘fe6b5ed0-89a5-43f8-a7af-ec69c47a0c25’,
“roles": [],
“sid": ‘e02e3a3a-12b3-4789-905f-4a4bd01d89ec’,
“auth_time": 1726863334,
“tid": ”fe6b5ed0-89a5-43f8-a7af-ec69c47a0c25”
}
Old, existing users do have the email claim in the token.
What was the solution for you @sandiprghane ?
Can anyone help?
Okay, got it, so currently you need a little self built workaround. Thank you very much!
The tickets read exciting in principle, but are not currently relevant for me.
Hello,
I have the following use case:
I am developing a multi-tenant SaaS with Fusionauth as IAM. Each tenant (customer) of our application gets its own tenant in Fusionauth. Each tenant should be able to configure itself whether its users can log in via SAML / OICD with an external IdP - e.g. the company's own Azure AD or Google Workspace.
I see from the documentation that the identity providers are intended for this and Fusionauth acts as a "service provider", correct?
Unfortunately, it seems to me that identity providers can only be configured for the entire Fusionauth instance, but not individually for each tenant. Is this the case?
If so, how can my use case be realised otherwise with Fusionauth?
Thank you very much,
Kind regards
Hello dear forum,
we use fusionauth in a scenario where a tenant corresponds to a club (sports, music etc.).
We want a club to be able to register independently on our website and a tenant to be created in the background. Before the club can use the platform, it should additionally - in whatever way - identify itself to us as a real club.
In the meantime, the tenant should be created, but still deactivated and not usable.
According to the documentation fusionauth does not provide the option to deactivate a tenant, as it is possible for users, for example, right?
Alternatively, one could introduce a flag 'verified' in the 'data' attribute of the tenant.
Is there a way to customize the login process to check other conditions besides the credentials, in this case the 'verified' attribute?
Does anyone have any other idea to implement the described use case?
Thanks!
