We also noticed that even with silent renewal, MFA code is getting triggered. This is very annoying for our users who stay on the page for long time.

Is there a way prevent MFA for SPA on every token refresh?

You can also use our GitHub action to easily add FusionAuth to a GitHub workflow.

Here's the action: https://github.com/FusionAuth/fusionauth-github-action

Here's doc about how to use it: https://fusionauth.io/docs/get-started/run-in-the-cloud/github-actions

@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...

@aswetnatex

docker pull fusionauth/fusionauth-app:latest

If you see an error message like https://YOURFUSIONAUTHSERVER/en?error=invalid_request&error_reason=missing_code_challenge&[…]The+request+is+missing+a+required+parameter%3A+code_challenge

it is because you have required PKCE for your application, but have not provided those parameters when attempting a login/registration. The links that we autogenerate in the app will not have a code_challenge by design, because those are dynamic for each request.

You can learn more about PKCE and turning it off on the applications core concepts page.

@david said in Why doesn't the example flutter demo code from github work on Android?:

Hi all,

I've been following the tutorial for using FusionAuth in a flutter app here: https://fusionauth.io/blog/2020/11/23/securing-flutter-oauth

Using this code works perfectly in iOS, but doesn't work on my Android device (Google Pixel 6, Firefox browser).

So I tried downloading the sample project from https://github.com/FusionAuth/fusionauth-example-flutter-dart/, and substituting my own values for the FusionAuth domain, etc. Again, this works perfectly in iOS, but on Android I never get redirected back to the app.

There is some information here https://fusionauth.io/community/forum/topic/602/error-fusionauth-s-login-page-redirecting-issue-on-android/5 about creating an interstitial web page to complete the redirect to the app for Android devices. Is this really required? Or is there some step I'm missing here that will make this work for an Android app directly without needing to set up a special web page?

Thanks,

David

Hi David,

It sounds like you're dealing with a tricky issue with OAuth redirects on Android. Here are a few things you might consider:

Custom URL Scheme and Deep Links: Make sure your Flutter app is properly configured to handle custom URL schemes and deep links on Android. This setup is crucial for redirecting back to the app after authentication. Check your AndroidManifest.xml file to ensure it has the correct intent filters for handling your OAuth callback URL.

Browser Configuration: Sometimes, browser settings or extensions can interfere with OAuth redirects. Try testing with different browsers or clearing the browser cache and cookies on your Google Pixel 6.

Redirect URI Handling: Verify that the redirect URI configured in FusionAuth matches exactly with the one used in your app. Any mismatch can cause issues with the redirect process.

Interstitial Web Page: The information you found about creating an interstitial web page is a workaround that some developers use to handle OAuth redirects on Android. This page can help bridge the gap between the authentication provider and the app. However, it should not be necessary if the redirect is properly configured.

Logs and Debugging: Enable logging and check the logs for any errors or issues related to the OAuth flow. This can provide valuable insights into where the process might be failing.

If you’re still having trouble, you might want to consult the FusionAuth documentation or their community forum for additional support.

Good luck, and I hope you get this resolved soon!

@egli said in Upgrading from 1.46.0 to 1.47.1 CSRF token issue with IdP:

Similar issue and was able to resolve it by following changes mentioned here:
https://fusionauth.io/docs/release-notes/#version-1-47-0 slice master

Can you explain in more detail?

@tschlegel thank you for reporting! This appears to be a bug. I have created the same issue within our GitHub issues page to follow up with, feel free to follow over there for status. I have prompted the engineering team as well so it gets on our "short" list.

https://github.com/FusionAuth/fusionauth-issues/issues/2863

We have this same problem 😔.

We followed the quickstart: https://fusionauth.io/docs/quickstarts/quickstart-javascript-react-web.
Like @richard-0, the only difference is we use a hosted FusionAuth instance (that is working well for our Laravel app).

The response is the same: missing_response_type

Going over the SDK it seems that there is no response_type parameter.

The SDK needs to be updated. Can you guys look into that?

Also: I am fairly confident that when I tried to set this up earlier this year, that it did work. So I have feeling this was changed fairly recently.

There is no webhook for this. You have a couple of options.

When the login event happens, you can look up the refresh token associated with that login event. You'd match based on application and time.

Then you can look up the application or tenant level refresh token lifetime and calculate out when the refresh token will expire.

Depending on the refresh token usage settings, refresh token lifetime might extend based on usage, so you might need to recalculate the lifetime based on that.

Then you'd know expiration time and refresh token id by querying this dataset.

You can also poll FusionAuth directly, using the APIs. You'd still need to keep track of valid refresh tokens in a separate datastore, then use the APIs to pull the valid refresh tokens. You can pull refresh tokens by user, but not at a coarser level of granularity. When you do so, use startInstant combined with the application or tenant level refresh token configuration.

@benlabbe2007: So in this example, the token is generate with the api password
this_really_should_be_a_long_random_alphanumeric_value_but_this_still_works.

The following request is sent to the FusionAuth server and returns the signed JWT.

curl --location 'http://localhost:9011/api/login' \ --header 'Authorization: this_really_should_be_a_long_random_alphanumeric_value_but_this_still_works' \ --header 'Content-Type: application/json' \ --data-raw '{ "loginId": "customer@example.com", "password": "password", "applicationId": "e9fdb985-9173-4e01-9d73-ac2d60d1dc8e" }'

That password is sensitive and you would not share that for a production environment.

In the example, you pass the token you received from the above call to the api server. The Microsoft.ASPNetCoreAuthentication.JweBearer validates the JWT by default. Since the JWT is signed, we can assume it has not been tampered with. It is possible to add custom validation criteria for special cases if needed.

The ValidAudiences UUID should not be considered sensitive as it is contained in the JWT and anyone with access to the JWT can see it.

@ahcfrontdoor I set up an application with the setting you are talking about and was allowed to register and proceed without any re-direction. Can you share a screen shot of your application registration tab. Please be sure to black out any sensitive information if necessary.

Hey @dan - thank you for your thorough reply! And sorry for the delay,

I think I've got the refresh token and the correct scopes. What I don't have currently is a backend - I only have a client-side application and my self hosted FusionAuth, currently. It seems like if I need to access the FusionAuth backend in order to pull the user's Discord token from the link, there will be no way to do this securely without a separate backend. Does that sound right?

While I understand this topic has been previously discussed, I believe it's still relevant due to the similarity in my use case.

I'm currently integrating Discord login into my application using the OpenID Connect identity provider. My goal is to implement a custom user experience that doesn't rely on FusionAuth's hosted login pages.

As mentioned in previous discussions, the current documentation doesn't provide a way to pass the PKCE code_verifier when requesting the "Complete an OpenID Connect Login" endpoint.

I'd like to propose two improvements:

Allow passing code, code_verifier (optional), and redirect_uri in the request payload. This would provide a more flexible and allow the usage of PKCE;

Allow passing an access token directly. This would eliminate the need for FusionAuth process the exchange step, similar to how Facebook's identity provider works (for example). This would probably also require the configuration of an endpoint to fetch the user email or username.

As a side note, since discord access_token is not a JWT I believe this cannot be done using the "External JWT" identity provider.

Hope you can help me with this.
Thanks!

@morten Check out this thread and please let me know if it works for you. https://fusionauth.io/community/forum/topic/2743/can-i-configure-a-tenant-application-as-an-external-identity-provider-for-other-tenants/8