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

No worries @laurent-michel !

FYI, this isn't just for applications.

For every resource in FusionAuth during creation you can either provide a valid UUID to control the value, or leave the UUID off and let FusionAuth create one for you.

@dan, thanks for the directions.

It looks lik you have a way to make the SSO redirect work for their widget, but not for the portal version of their solution. The portal works with a "redirect" URL parameter that the authenticating party receives and needs to send back after authentication.

I don't think FA supports arbitrary URL parameter forwarding, so this is pretty much a no go directly out of the box.

I'll have a look at the widget, maybe that's a better solution for us anyway.

Ok this is how I fixed the post_logout_redirect_uri issue.

In my logoff method, I did this to remove the local cookies

c99db979-5e36-4e07-8cbd-8ce25bd73775-image.png

Then because I could not use the Owin..OIDC..PostLogoutRedirectUri in the OpenIdConnectAuthenticationOptions to pass the client_id

At the end of the logoff method, I just did this:

39f0427a-f30a-4e54-b719-1c6689476674-image.png

This removed the FusionAuth session, does the log out, and redirects to my home page

Thanks to all who tried to help out

Please also note - We are currently logging in with a custom UI that is not related to the FusionAuth instance. We're just utilizing the APIs to simulate that login.

You want to look at https://fusionauth.io/docs/v1/tech/lambdas/samlv2-response-populate/ This can update the email/nameId before it is sent over to the special SP.

You will want to create a separate application and set the Response Populate Lambda to the lambda which does this transformation. This can be done via the UI as illustrated here: https://fusionauth.io/docs/v1/tech/samlv2/

Hey folks, I think I spoke too soon with my response 14 days ago. I misunderstood and assumed the id_token was available. There is a token on the reconcile lambda, but it is the access_token, not the id_token. My apologies.

That said, there is some work happening on issue 323 that you probably want to track: https://github.com/FusionAuth/fusionauth-issues/issues/323 (a comment or two way at the bottom). It's not finished yet, but we're looking at ways to make the id_token available to the open id connect reconcile lambda.

@harish_reddy

You are asking if there is a way for the client to somehow know the user's account on the server has been modified and therefore refresh the JWT? I suppose you could have the server somehow push info to the client using something like websockets.

Or are you asking if the client can check every so often and refresh the JWT even before it is expired? In this case, you could shorten the lifetime of the JWT, or just refresh the JWT periodically using this API: https://fusionauth.io/docs/v1/tech/apis/jwt/#refresh-a-jwt

Or am I misunderstanding the question?

Hi @Timon ,

We have no integration with password vaults. Please file a github issue with your use case if this is important to you: https://github.com/fusionauth/fusionauth-issues/issues

We store a number of secrets (keys, api keys, client secrets) and outline how to rotate them here: https://fusionauth.io/docs/v1/tech/tutorials/key-rotation/

But FusionAuth isn't a general purpose secrets manager.

Can you explain a bit more about what you are looking to do?

Use the managed domains feature. From the docs:

Adding one or more managed domains for this configuration will cause this provider not to be displayed as a button on your login page. Instead of a button the login form will first ask the user for their email address. If the user’s email address matches one of the configured domains the user will then be redirected to this login provider to complete authentication. If the user’s email address does not match one of the configured domains, the user will be prompted for a password and they will be authenticated using FusionAuth.

Documentation:

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

https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/

Hi Maciej, I dont thing that I am messing up something.

Finally I got it up and running by just "try and error". With an old FusionAuth documentation and examples

React App: gets the token from FusionAuth and communicates with this token to the Spring Boot Backend

Spring Boot Backend: Checks the token using FusionAuth as JWS Issuer and rejects or accepts as authorised

@dadasaheb-patil

Welcome! I have passed this along to our sales development team for a reach-out and introduction. FusionAuth can be used in a number of ways to meet various use cases. Our core concepts section offers a review of some of the basic functionality within FusionAuth, as well as our Five Minute setup guide to get you up and running quickly.

Links are included below

https://fusionauth.io/docs/v1/tech/core-concepts/
https://fusionauth.io/docs/v1/tech/5-minute-setup-guide/
https://fusionauth.io/docs/v1/tech/getting-started/

Regarding roles - there are a number of ways that you can map app users and roles. One common method is with a JWT and a lambda.

https://fusionauth.io/docs/v1/tech/core-concepts/roles/
https://fusionauth.io/docs/v1/tech/lambdas/

Roles are available in the JWT upon successful authorization and are also returned as part of the user’s registrations.

I hope this is a good place to start! Let us know if you have more specific questions and we wil do what we can to address them here.

Thanks,
Josh

Hi @Joshua,

It seems this is working as expected as @egis described. FusionAuth needs to find an email claim in the response from the userinfo endpoint (or username, depending on the linking method) before running the reconcile lambda. I confirmed this by linking on username instead and setting preferred_username to sub and was able to confirm that the reconcile lambda executed. I had mistakenly thought that the lambda ran before linking occurred and could be used to populate email.

In my case, the issue is that my IDP (AzureAD) does not return email from the userinfo endpoint. AzureAD is very restricted in what it returns from the userinfo endpoint and allows not customization or claim mapping. It seems AzureAD populates the email claim with Primary SMTP email address, which is reserved field from Exchange, however we don't use Exchange/Outlook365 as our email service provider.

In Azure, claim mapping can only be applied to the access and id tokens and not what is returned from the userinfo endpoint. However, these tokens are not available to the lambdas.

I believe there is already a Github issue created for this:
https://github.com/FusionAuth/fusionauth-issues/issues/323

In the meantime, I'm using SAML instead, because AzureAD allows me to map email address to user.mail which is where it is stored in our case.

@michael-schramm

You can also ask in our slack channel if it suits you 🙂

https://fusionauth.io/community/

Thanks,
Josh

It would appear that you are requesting functionality similar to scopes in OAuth:

https://github.com/FusionAuth/fusionauth-issues/issues/218
https://github.com/FusionAuth/fusionauth-issues/issues/275

Please upvote these issues if they apply to your use case.

I don't see a way to manage "permissions" in fusion auth (what a role would allow a user to do) - so I assume that concept would be left to the individual micro-services to handle.

I believe that you are correct. You would have to write this integration code.

Roles can be used. They are entirely free form. Meaning you can assign the role of "monster_maker_person" to a user and define what the role can and cannot do at the integration code level.

A few other customers have unique implementations regarding roles and permissions. You can read more (at a high level) about them below.
https://fusionauth.io/blog/2021/06/15/sunfinity-fusionauth-python/#undefined

First question is if my "mapping" follows the best practices for fusion auth. I want to make sure that I don't map in a way that means I'll be fighting with the solution.

The answer to this question might be in the details of the integration. From afar, it seems reasonable to me. We do offer professional services/contracts should you need additional support in your integration.

Second quesiton is, how would the community suggest that we model the new requirement in fusion auth, or is the capabilities of fusion auth not a good fit for this use case?

After browsing our open issues (https://github.com/FusionAuth), feel free to log your own use case if not covered.

I hope this helps!

Thanks,
Josh