@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

Hi @dan

If you require any more details or can give some suggestions kindly let me know I am still unable to figure out the error causing here

@cyrill-lippuner

Ah, ok the scope of the question/request makes sense to me.

With the disclaimer that I have not used the typescript library extensively (yet), when I search this library for "patch" it does appear that we do support PATCH.

Can you confirm that you see this as well (or possibly I am overlooking something)

https://github.com/FusionAuth/fusionauth-typescript-client/blob/master/src/FusionAuthClient.ts (this is the library I searched)

Thanks
Josh

We don’t currently resolve any environment variables in the themes, or anything other than what is documented here: https://fusionauth.io/docs/v1/tech/themes/template-variables/

But you can set variables in the Helpers template using assign that can be used in other templates. You could use a templating language like jinja to build the Helpers template at build time and then a script to load it during deploy. (Or even sed.)

You can also create different themes (a dev theme, a qa theme) and assign them via scripts to the different environments (unsure if you are using different tenants to represent environments or different FusionAuth instances, but the concept is the same).

@pleymor said in CORS error when posting to /oauth2/token:

Access to XMLHttpRequest at ... has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

The Same Origin Policy (SOP) is a security measure standardized among browsers. It is needed to prevent Cross-Site Request Forgery (CSRF). The "Origin" mostly refers to a "Domain". Same Origin Policy prevents different origins (domains) from interacting with each other, to prevent attacks such as CSRF (Cross Site Request Forgery) through such requests, like AJAX. In other words, the browser would not allow any site to make a request to any other site. Without Same Origin Policy , any web page would be able to access the DOM of other pages.

This SOP (Same Origin Policy) exists because it is too easy to inject a link to a javascript file that is on a different domain. This is actually a security risk ; you really only want code that comes from the site you are on to execute and not just any code that is out there.

If you want to bypass that restriction when fetching the contents with fetch API or XMLHttpRequest in javascript, you can use a proxy server so that it sets the header Access-Control-Allow-Origin to *.

If you need to enable CORS on the server in case of localhost, you need to have the following on request header.

Access-Control-Allow-Origin: http://localhost:9999