Hey folks, I think I spoke too soon with my response 14 days ago. I misunderstood and assumed the id_token was available. There is a token on the reconcile lambda, but it is the access_token, not the id_token. My apologies.

That said, there is some work happening on issue 323 that you probably want to track: https://github.com/FusionAuth/fusionauth-issues/issues/323 (a comment or two way at the bottom). It's not finished yet, but we're looking at ways to make the id_token available to the open id connect reconcile lambda.

@harish_reddy

You are asking if there is a way for the client to somehow know the user's account on the server has been modified and therefore refresh the JWT? I suppose you could have the server somehow push info to the client using something like websockets.

Or are you asking if the client can check every so often and refresh the JWT even before it is expired? In this case, you could shorten the lifetime of the JWT, or just refresh the JWT periodically using this API: https://fusionauth.io/docs/v1/tech/apis/jwt/#refresh-a-jwt

Or am I misunderstanding the question?

Hi @Timon ,

We have no integration with password vaults. Please file a github issue with your use case if this is important to you: https://github.com/fusionauth/fusionauth-issues/issues

We store a number of secrets (keys, api keys, client secrets) and outline how to rotate them here: https://fusionauth.io/docs/v1/tech/tutorials/key-rotation/

But FusionAuth isn't a general purpose secrets manager.

Can you explain a bit more about what you are looking to do?

Use the managed domains feature. From the docs:

Adding one or more managed domains for this configuration will cause this provider not to be displayed as a button on your login page. Instead of a button the login form will first ask the user for their email address. If the user’s email address matches one of the configured domains the user will then be redirected to this login provider to complete authentication. If the user’s email address does not match one of the configured domains, the user will be prompted for a password and they will be authenticated using FusionAuth.

Documentation:

https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/

https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/

Hi Maciej, I dont thing that I am messing up something.

Finally I got it up and running by just "try and error". With an old FusionAuth documentation and examples

React App: gets the token from FusionAuth and communicates with this token to the Spring Boot Backend

Spring Boot Backend: Checks the token using FusionAuth as JWS Issuer and rejects or accepts as authorised

@dadasaheb-patil

Welcome! I have passed this along to our sales development team for a reach-out and introduction. FusionAuth can be used in a number of ways to meet various use cases. Our core concepts section offers a review of some of the basic functionality within FusionAuth, as well as our Five Minute setup guide to get you up and running quickly.

Links are included below

https://fusionauth.io/docs/v1/tech/core-concepts/
https://fusionauth.io/docs/v1/tech/5-minute-setup-guide/
https://fusionauth.io/docs/v1/tech/getting-started/

Regarding roles - there are a number of ways that you can map app users and roles. One common method is with a JWT and a lambda.

https://fusionauth.io/docs/v1/tech/core-concepts/roles/
https://fusionauth.io/docs/v1/tech/lambdas/

Roles are available in the JWT upon successful authorization and are also returned as part of the user’s registrations.

I hope this is a good place to start! Let us know if you have more specific questions and we wil do what we can to address them here.

Thanks,
Josh

Hi @Joshua,

It seems this is working as expected as @egis described. FusionAuth needs to find an email claim in the response from the userinfo endpoint (or username, depending on the linking method) before running the reconcile lambda. I confirmed this by linking on username instead and setting preferred_username to sub and was able to confirm that the reconcile lambda executed. I had mistakenly thought that the lambda ran before linking occurred and could be used to populate email.

In my case, the issue is that my IDP (AzureAD) does not return email from the userinfo endpoint. AzureAD is very restricted in what it returns from the userinfo endpoint and allows not customization or claim mapping. It seems AzureAD populates the email claim with Primary SMTP email address, which is reserved field from Exchange, however we don't use Exchange/Outlook365 as our email service provider.

In Azure, claim mapping can only be applied to the access and id tokens and not what is returned from the userinfo endpoint. However, these tokens are not available to the lambdas.

I believe there is already a Github issue created for this:
https://github.com/FusionAuth/fusionauth-issues/issues/323

In the meantime, I'm using SAML instead, because AzureAD allows me to map email address to user.mail which is where it is stored in our case.

@michael-schramm

You can also ask in our slack channel if it suits you 🙂

https://fusionauth.io/community/

Thanks,
Josh

It would appear that you are requesting functionality similar to scopes in OAuth:

https://github.com/FusionAuth/fusionauth-issues/issues/218
https://github.com/FusionAuth/fusionauth-issues/issues/275

Please upvote these issues if they apply to your use case.

I don't see a way to manage "permissions" in fusion auth (what a role would allow a user to do) - so I assume that concept would be left to the individual micro-services to handle.

I believe that you are correct. You would have to write this integration code.

Roles can be used. They are entirely free form. Meaning you can assign the role of "monster_maker_person" to a user and define what the role can and cannot do at the integration code level.

A few other customers have unique implementations regarding roles and permissions. You can read more (at a high level) about them below.
https://fusionauth.io/blog/2021/06/15/sunfinity-fusionauth-python/#undefined

First question is if my "mapping" follows the best practices for fusion auth. I want to make sure that I don't map in a way that means I'll be fighting with the solution.

The answer to this question might be in the details of the integration. From afar, it seems reasonable to me. We do offer professional services/contracts should you need additional support in your integration.

Second quesiton is, how would the community suggest that we model the new requirement in fusion auth, or is the capabilities of fusion auth not a good fit for this use case?

After browsing our open issues (https://github.com/FusionAuth), feel free to log your own use case if not covered.

I hope this helps!

Thanks,
Josh

Our HA cloud offerings, outlined on fusionauth.io/pricing are aimed at the following use cases:

Large production needs Reliability required Higher monthly active users

Development doesn't typically fall into any of these :).

With HA you get an SLA, a custom URL (auth.example.com instead of example.fusionauth.io) and an architecture capable of handling more users.

You might want a custom URL to test your DNS/cookie config. Or you might want to load test (please don't load test with a basic cloud deployment, it won't tell you anything about production performanc).

If you want to derisk this early, in both these cases, we recommend standing up a temporary HA instance, applying your configuration, testing, and then tearing down the HA instance.

https://github.com/FusionAuth/fusionauth-issues/issues/1394 - logged for feature tracking. Feel free to add your own comments or observations as you see fit

That looks like you haven't applied the migrations needed. Per the release notes, that upgrade will require database migrations: https://fusionauth.io/docs/v1/tech/release-notes/

As a reminder, you can have fusionauth do the database migrations, but only if you are in development mode (check fusionauth.properties). If you are in production mode, you'll have to apply the migrations yourself, as outlined here: https://fusionauth.io/docs/v1/tech/installation-guide/upgrade/#database

Yes, you can search for users who are set to

"active" : false

just like any other user

The user can be retrieved but will have a status of {"user" : { "active" : false } }
The user cannot be updated but will instead have this error return

{ "fieldErrors": { "userId": [ { "code": "[inactive]userId", "message": "The User with Id [00000000-0000-0000-0000-000000000007] is inactive and cannot be updated until it is reactivated." } ] } }

Yes, this is the functional equivalent in the UI.

Soft delete is the preferred method.

Hi @ivona, thank you for writing in!

Can you let me know of any output in the error event log for both OAuth and apple config? This may help to troubleshoot this issue.

In the meantime, please feel free to take a look at some of our similar, Apple-related posts on our forum. Here are a couple of posts that may prove useful:

https://fusionauth.io/community/forum/topic/752/not-able-to-login-with-apple-id/6
https://fusionauth.io/community/forum/topic/752/not-able-to-login-with-apple-id

In the meantime I will dig further into this issue on my end and see if I can reproduce it.

Talk soon,

Akira

@elliotdickison said in Awkward OAuth logout in mobile app:

@maciej-wisniowski We ended up going with your solution and it's working alright, thanks for that!

@robotdan One suggestion for you all: I found the naming of the "AllApplications" value for the application.oauthConfiguration.logoutBehavior setting a bit confusing. As far as I can tell all the "AllApplications" value it really means is "show the OAuth2 logout page". That page can be used to log out of all apps (that's the default template behavior), but it doesn't have to be used that way. Per the suggestion from @maciej-wisniowski we are using the page to log the user out of only one app and show a "successfully logged out" message. Maybe to avoid a breaking API change the value "OneApplication" could be added in addition to "AllApplications" and "RedirectOnly". That value could use the same OAuth 2 logout template but maybe set a variable that could be used to conditionally turn off the logout-of-all-apps behavior. Just a thought.

Thanks for the suggestion @elliotdickison - please do open a GH issue with this suggestion and how you'd like the logout to behave in your use case.