@mark-robustelli said in 3rd Party Authentication:

@it-contracts Can you please share the OAuth settings you have for your application? In the Fusion Auth Admin UI select Applications. Select Edit or view for your application. Share the OAuth and JWT settings. Be sure to remove any sensitive information before posting here.

I did not make any settings in JWT, so there is nothig there.

In the OAUTH section here's what I have:

Client Id - Id generated by fusionAuth. Client secret - Secret generated by FusionAuth. Client Authentication - Set to Required PKCE - Set to Not Required. Generate refresh tokens - Checked Debug enabled - Checked (No idea if this does anything in the Cloud configuration). URL validation - Set to Exact Match Authorized redirect URLs -http://localhost:8080/MyAppName/FusionAuthLogin Authorized request origin URLs - Not Set Logout URL - http://localhost:8080/MyAppName/FusionAuthLogout Logout behavior - Set To All applications Enabled grants - Checked "Authorization Code" and "Refresh Token" Require Registration - Checked

That's it.
Thank you Mark
Rudy

It is likely that the link for the password has simply expired, meaning it will no longer work. There could be two possible explanations.

You may want to review the timeouts that you have established for your Forgot Password Workflows Tenants > Your Tenant > Advanced > Change password to ensure that you are satisfied with their duration.

The user sent themselves two password reset emails in a row. The first password reset link sent would be invalidated (expired) when the second request for a password reset is submitted by the user. If the user then clicked on the first password reset link (in their inbox), then they would have seen an expired message.

@shyamsundar-k said in How to generate and authorized java spring controller using JWT:

We need to pass the token in the API header as Authorization: Bearer<token> But what is the process so that I can validate the endpoint with the valid token if the token is invalid or does not have the required roles or scope then I should get 401 else I should be able to access the API successfully.

Once you have a token in your API, you can validate it in two different ways. But it's worth noting that to validate the token, you must validate the signature and then the claims.

First option: use a library to validate the signature. Most languages have options. For java, you can use fusionauth-jwt, the readme has sample code.

Second option: use the validate API. You could use the FusionAuth client library to make this call if you'd like.

The first means you have to pick a library. The second means you have to make a network call.

Either way, after you validate the signature, you need to check the claims (issuer, audience, expiration, custom claims) to make sure they are what you expect.

Here's more about how to consume a JWT.

@mculley, did this work for you as well after you recreated the tenant again?

@skorupa-pawel I saw this on Firefox in the past but never on Safari.

Does this apply to all applications?

Do you have a logout url configured in the OAuth tab? Does that URL exist?

They run in AWS.

FusionAuth increments each release using semantic versioning.

So after 1.5 comes 1.6, then 1.7, then 1.8, then 1.9, then 1.10, then 1.11.

So 1.5 is about 40ish versions behind 1.47.1.

Hi @saugat-nepal ,

Thanks for using FusionAuth.

Is this the process you are trying to do? https://min.io/docs/minio/linux/operations/external-iam/configure-openid-external-identity-management.html

Or is there another document you are trying to work through?

When using FusionAuth as the identity provider for a third party piece of software, it's often helpful to turn on debugging (under Application -> Your Application -> OAuth, then turn on Debug enabled). Then go through your login process. Then check the Event Log, under System -> Event Log. This should give you additional information about the handshake and OIDC process.

Please share those logs here (please remove any sensitive information from them) and we'll see if we can help.

JDK 17 turned off RSA-SHA1 XML signature support. It can be re-enabled by modifying java.security file in the JDK conf/security folder.

This is addressed in the release notes and Github issue 1814.

Hiya @jkyser ,

Hmmm. What version of FusionAuth are you running?

It looks like this is a known issue that was fixed in release 1.46.0.

@eric-vigiani Sorry about that! We pull in the code for server.py from GitHub, and it looks like it is missing.

We have a new, simpler python flask tutorial: https://fusionauth.io/docs/quickstarts/quickstart-python-flask-web

which we just reviewed and tested.

Sorry for the hassle!

@bhardwajmunish88 From the stackoverflow link:

According to this github issue this is corrected by using docker 20.10.5.

Can you try with a later version of Docker? I think this is due to the Java Docker image, and isn't an issue with FusionAuth.

Hiya @benjamineroommen ,

I'm not sure what you mean? Are you talking about the JWT generated for a login event?

The issue with the redirect URI specified in your code. FusionAuth is indicating that the redirect URI you provided is invalid.
The redirect URI must match the one registered for your FusionAuth application.

Hiya @diego-carreras !

Hmmm. Did you ever solve this? I have not run across this before.

Did you try other email clients? Did you search the MS Outlook forums? Did you turn on the email debugging?

Hi there!

I don't have any experience with Apache Traffic Server to be honest but are you running your FusionAuth instance with HTTPS? If so, does Apache Traffic Server trust the FusionAuth certificate?

I did manage to make it work locally by configuring the reverse proxy like shown on their docs and adding this mapping to the remap.config file:

map http://fusionauth.local:8080/ http://fusionauth-fusionauth-1:9011/

This will make it proxy requests to http://fusionauth-fusionauth-1:9011/ when it receives a request with Host: fusionauth.local:8080. Then, I added fusionauth.local to my /etc/hosts to point to Traffic Server.

This was enough to reach the FusionAuth instance, but I still needed to configure some HTTP headers to make it function correctly. Using Traffic Server's header rewrite plugin, I changed the config above to:

map http://fusionauth.local:8080/ http://fusionauth-fusionauth-1:9011/ @plugin=header_rewrite.so @pparam=fusionauth.conf

And created a fusionauth.conf file with the needed headers:

set-header X-Forwarded-Host %{CLIENT-URL:HOST} set-header X-Forwarded-Port %{CLIENT-URL:PORT}

Please let me know if that works.

@dan The configuration files and logs are inaccessible, assuming you're talking about the ones residing up a directory from /fusionauth-app/.

Thank you for stating the risks of the leakage. The only thing that raised flags here was the default fusionauth.properties file in the template directory had the default database user and password, but those should be, and were, changed when installing.

I will fork and submit a PR later tonight or this week.

Thanks again.

@dot-realities

Hmmm. It seems like you want to have email verification take place entirely outside of FusionAuth. Is that the case?

If so, you should:

suppress sending any emails to FusionAuth, which will typically will verify emails (you can turn that off by setting tenant.emailConfiguration.implicitEmailVerificationAllowed to false) send emails yourself, using whatever system you want verify the user's email directly, using an API key (search for Administratively).

Does that meet your needs? If not, please provide more information.

@joaogoncalves Hiya, I don't think that is supported. I'd suggest using two different Application configurations in FusionAuth, though I'm sure that's something you've already considered.

Feel free to file a feature request: https://github.com/FusionAuth/fusionauth-issues/issues/