What do you mean by 'user logs into desktop application'? How would you like to implement it?
If you implement step 1. as I've described in my previous post (by opening the browser window to log the user in) then there will be an SSO session in the browser already.
This is the flow that OAuth specs define for native applications, eg. desktop ones: https://datatracker.ietf.org/doc/html/rfc6749#section-9

This means that in step 3. when the browser is opened, the user is already authenticated.

I have enjoyed these books:

https://www.manning.com/books/oauth-2-in-action very specific to OAuth, lots of code)

https://www.apress.com/gp/book/9781484250945 More focused on bigger identity strategies and problems.

Also, the IDPro body of knowledge is free and useful:

https://idpro.org/body-of-knowledge/

Hiya,

It depends on what you mean by "dynamic". What are they based dynamically based on?

If they are based on attributes of the user, you could pull them from user.data. If they are random or time based, you could use the method outlined here: https://stackoverflow.com/a/51554484/203619

I'd also suggest testing to see if any parameters you add to the confirmation link are received by the destination page. I'm not sure if any processing happens that might strip unknown parameters. (I don't think so, but am not certain.)

Let us know what you find!

Hiya,

You should review the APIs to determine if FusionAuth can meet your needs.

You can sync almost everything.

One notable exception is the password hash and other info around it (salt, etc) which are not available via API call.

@mg

Good question! Aspects of this question are covered in our FAQ.

https://fusionauth.io/license-faq/#19
https://fusionauth.io/license-faq/#11

Additional information can be found by contacting our sales team should you have a business need for continuity plans.
Please use the contact form found on the home page.

https://fusionauth.io/contact/

Thanks,
Josh

Instead of using an OpenIdConnect authentication method I instead used a JWT Bearer like so:

services.AddAuthentication(options => { options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme; options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; }) .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, opt => { opt.Authority = "https://my.fusionauth.instance"; opt.RequireHttpsMetadata = true; opt.SaveToken = true; opt.TokenValidationParameters = new TokenValidationParameters() { ValidAudience = "my application id / client id"; }; });

I could add the oidc back and use it to so long as I decoreate my Authorize attributes with that authentication scheme.

Now the pipeline calls my fusion auth instance and checks the token matches and has not been tampered with. To get this to work I had to create my own Key in FusionAuth and apply it to the JWT settings of my application. Then when the runtime calls https://my.fusionauth.instance/.well-known/jwks.json it returns the key needed to validate the token.

Now to get roles to work ...

A couple of things:

https://fusionauth.io/docs/v1/tech/troubleshooting/#troubleshooting-email has troubleshooting tips worth checking out.

The UI copy doesn't copy the SMTP password, so double check that as well.

Good question.

JWTs are either signed or encrypted. For the most part, you will encounter signed JWTs. When a JWT is created by an authorization server, it is signed. The signature essentially functions as a way to say "this payload has been signed using this algorithm. If the payload is different than what was signed, then this JWT is invalid." It is important to not pass sensitive data in a JWT payload for the reason that it can be viewed, but if a malicious actor tries to tamper with the JWT, the signature will no longer match it, and it will be invalid.

Yes, you can put anything in the user object that is documented here: https://fusionauth.io/docs/v1/tech/connectors/generic-connector/#using-the-generic-connector

You can return registrations which contain roles as outlined in the sample JSON in the link above.

Hope that helps!

Is this the same as https://fusionauth.io/community/forum/topic/1317/error-after-updating-the-password ? or different?

Please share any logfiles you see (you can go to "System" -> "Logs" in the admin UI to view them).

Hi @saitulasiram94!

FusionAuth can act as both SP and IdP via SAML.

You may want to review how Gmail integrates via SAML. If Gmail (as Idp) supports an SP or IdP initiated login from FusionAuth, then you should be able to integrate.

I have included our relevant documentation below.

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

Thanks,
Josh

With advanced threat detection you can block access to applications via IP ranges (it's touched on briefly here: https://youtu.be/pjGxOXamVfk?t=1209 ).

Advanced threat detection requires an enterprise license. Currently you can't lock a certain user to an IP range, though.

Please feel free to file a feature request with details of this use case if you'd like to see this implemented.

Tested and verified this works. Feel free to use theme.data to your heart's content, @mmcnamara !

@joshua Thanks for confirming the behavior I am seeing. I will try using a library to validate the jwt instead.

In 1.28.0, FusionAuth introduced a linking strategy and a first class 'link' object. This is part of the community/free edition.

This is how I'd approach that. You'd have to get the user to login via their social account and get their unique user Id (for, say, Google). This could be done via a page in your application.

Then you'd take that Google user Id and create a link using the APIs: https://fusionauth.io/docs/v1/tech/apis/identity-providers/links/

Here's more on this: https://fusionauth.io/docs/v1/tech/identity-providers/#linking-strategies

After the link is created, the next time the user went to login, they could use either their old email/password creds or the linked social login.

@yb98

I think what you are looking for is OAuth's back-channel logout. This is under consideration under ticket 465.

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

As a workaround, you would have to use a backend (or another environment that can appropriately hide credentials) and make a call to revoke the refresh token on a user.

I may be misunderstanding your workflow, but I believe the above should point at a possible solution.

Thanks,
Josh

@james-hudson

One thing to try would be to turn on email debugging/logging to see if you are offered any additional clues.

Additional information can be found on our troubleshooting page

https://site-local.fusionauth.io/docs/v1/tech/troubleshooting/#troubleshooting-email

Thanks,
Josh

The server that issues and signs the JWT is called the Authorization Server. This is what FusionAuth is, as we issue and sign the JWTs which are then presented to other servers via API calls.

The servers that are connected to resources that a user is trying to access by first authenticating with a JWT are called Resource Servers.

So, for example, if you have a ToDo app, where a user is trying to access a list of ToDo items, the user would first authenticate with the external IdP. Then the JWT is issued by that IdP, passed to the client, and then the client would present that JWT to the resource server to gain access to the ToDo items.

For what it's worth, in SAML the auth server coincides with the IdP, and the resource server coincides with the Relying Party.

thanks @joshua,

1361 seems about client secret rotation, not refresh tokens.

But the implications seem the same to me: if you rotate - whatever you rotate - you have the problem above and the need of a grace period.

I think my question is answered anyway, will look forward to adopt refresh token rotation when it's safer to do that in the face of clients that use parallel requests.

cheers
f