This is an example of Third-party Service Authorization.

We store the tokens on the Link, but leave the refresh operation up to the software needing to access the third party API.

This approach has some tradeoffs, but gives more granular control to the application that needs the access token.

How it works:

The developer sets up an 'authorize' button in their application We take care of the authorization/authentication/storage of the refresh token.

... time passes

When they need an access token, they call our APIs to get the refresh token for a particular user They call the 3rd party service to get the access token, They use the access token.

If the access token expires while they need it, they can get the refresh token again and then get an access token.

@mike-rudat

I wanted to confirm that the generic messenger does not have re-try logic built-in on a failure.

@mike-rudat

Yes, I verified using the SAML V2 and PagerDuty Integration. From the documentation, copy the Login URL from the FusionAuth SAML v2 Integration details section and paste it in PagerDuty’s own Login URL field and append the idp_hint query string parameter for an external IdP. In turn, the user was taken directly to the IdP login screen.

@mark-robustelli Thanks, Mark. After having worked with FA some more, I now realize that I don't need it to be a GET. Thanks for the response.

@as-redbios Can you please offer a little more detail. What version of FusionAuth are you using? What are the user actions that are taking place? What do you mean by "always force to re login"? Is this every page they visit?

This endpoint returns a 404 for an invalid or expired verificationId. It is also the case that you can only use a verificationId once for verification before it becomes stale.

What does this mean for your workflow? In my case, I was trying to verify a user's registration in the same request cycle as verifying their email. To do this, I needed to fetch the user response to get the user ID to verify the registration. Naturally, I was doing this after posting the email verification -- the result being said 404.

So, in terms of workflow, if you need to look up a user by verificationId, be sure to do it before you actually use the ID for verification.

Let me know if I got any of this wrong @arihantverma52

@dan Also, depending on the workflow, if a user does NOT federate but does NOT check "trust this computer" they will NOT establish "MFA trust". Without trust, a user will be prompted to MFA again. Of couruse, With "MFA trust", they will not be prompted. This answer is implicit to this conversation, but MFA policies and FusionAuth center around this check box and trust (with the current edge case of Federation noted).

@mr-sahand said in Fusion auth single sign on issue:

I have two same enabled applications defined on fusionauth each representing a separate web application hosted on my local. I have also created two applications on an azure ad tenant and connect my fusion auth applications to them via two saml v2 identity provider I have created on fusionauth. I have created one user on AzureAD tenant and only added that user to one of the applications.
I can launch the web application which the azure ad user has access to and log into the application using it. Now when I try the other web application on the same browser what happens is it logs into the application without even going to a login page. What I am expecting is the second application to be rejected to log in as the azure ad user does not have access to it.
What do I need to acheive the desired behaviour?

I am having the same single sign on issue now. Did you find any solution?

FusionAuth has a bunch of import scripts, but one that you are probably most interested in is the CSV importer, which takes a CSV file and then calls the user import API.

Here's the link: https://github.com/FusionAuth/fusionauth-import-scripts/tree/main/csv

Of course, LDIF is not CSV.

Instead of using a CSV gem to get the list of users and their attributes, use a gem that can read LDIF. Here's a candidate. https://www.rubydoc.info/gems/ruby-ldap/0.9.19/LDAP%2FLDIF.parse_file but I'm not sure what the state of the art for ruby LDIF parsing is nowadays.

If you pursue this, please submit a PR to that repo because there may be other folks who want to import users from LDIF

An alternative would be to have them manipulate the LDIF file into CSV and import that using the csv importer. See https://www.google.com/search?client=firefox-b-1-d&q=ldif+to+csv for some examples on how to do the LDIF->CSV transformation.

Ensure that the source machine that is building your image is the correct architecture type.

https://www.reddit.com/r/kubernetes/comments/13lurdl/kubernetes_error_exec_usrlocalbinyarn_exec_format/?rdt=39252

For instance, if you are building a K8's cluster running linux (x86) but have built the image locally on a Apple M2 Mac (ARM based), then you will need to instruct docker to use the build x command to build a multi-platform build or change the source build machine.

@vatsal We did not

Hello there,
I feels like you are encountering some complex issues with running FusionAuth in Azure Container Apps and using KrakenD as a proxy.

For the Proxy Configuration Warning, be ensure that your FusionAuth instance is aware of the correct external URL and headers. You might need to set the FUSIONAUTH_URL environment variable appropriately.

Releated KrakenD, you could configure it to correctly handle the necessary headers for FusionAuth. Be sure your KrakenD configuration includes the necessary routes and headers for FusionAuth's admin and OAuth endpoints.

Consider checking the FusionAuth and KrakenD documentation for any specific configurations needed for Azure environments.

If the issue still did not get solved, you might want to reach out to FusionAuth support directly for more tailored assistance.

Hope it helps.

@tony-blank yes please help me.