Clarification of some confusions

tstamadianos

Hello!

I'd like to start by thanking you for creating FusionAuth! We were looking for a solution we can keep on the same AWS subnet for faster and more reliable authentication calls, in addition to maintaining ownership of the user data on our own Postgres database. While the concepts are complex, I was able to grasp the general idea and implement JWT auth in ASP.NET Core, but I still have a few things I need to clarify. As an aside, I would be happy to share this code so you can have an example of how to do API security in ASP.NET Core!

Below are some thing I would deeply appreciate some clarification on. I think other .NET Core developers would also be sharing some similar questions, so I hope your answers will help them as well!

1. Is FusionAuth using OpenID Connect?

From my research & reading (this page helped a lot), it appears that OpenID is a standardized set of claims that should be included in OAuth2 tokens. With that in mind, is the token sent by FusionAuth is therefore outside of the scope of OpenID since it contains a few extra claims, as listed here. So, am I correct in saying that FusionAuth is not using OpenID connect?

2. How long does it take for role changes to come into effect?

Recently I was testing access levels. I assigned myself "Admin" and performed some endpoint tests in Swagger. Then I changed my role to one of lesser permissions, but I was still able to use the admin-only endpoints. It was only after I logged out & logged back in that the new permissions took effect. I'm not sure if this is an oversight of my understanding of OAuth2, or a configuration setting I haven't changed, or something with how ASP.NET Core JWT middleware handles token validation.

3. Should the frontends be talking to FusionAuth directly?

The confusion here stems from the documentation in the React demo page, specifically here. It states that our frontends shouldn't be talking to the FusionAuth directly, but rather pipe through a backend. To give some background on our project, we have a monolithic backend API that's going to serve data to serve a frontend written in React. The backend endpoints are secured with JWT. We want users to be able to sign-in with username & password, but also CarbonCure company employees to sign in with their Google account. We also have tinier smaller AWS lambdas that will also be periodically running and talking to this endpoint. I'm just not sure what role our monolithic backend server plays into all this. How do we get the nifty sign-in page on the frontend when we need to hide all the secrets and the like in the backend? Is this something we even have to do?

Once again, thank you for this product. We look forward to using the premium features as we grow!

tstamadianos

Just to give some clarification on my clarification questions,

In question #1,

With that in mind, is the token sent by FusionAuth is therefore outside of the scope of OpenID since it contains a few extra claims, as listed here.

should read as a question:

With that in mind, is the token sent by FusionAuth is therefore outside of the scope of OpenID since it contains a few extra claims, as listed here?

Likewise, in question #2 I'm just wondering what could be the cause of this behaviour.

I apologize for my early mid-coffee post that may have been just as confusing to you!

Thanks again!!

dan

@tstamadianos welcome to the FusionAuth community!

Is FusionAuth using OpenID Connect?

Yes, OIDC is supported. This doc may be helpful. In order to get the id_token you must need to request the openid scope.

The id_token claims are documented here.

How long does it take for role changes to come into effect?

How long is your JWT good for? From what I can tell, it looks like your admin only endpoints are reading the roles from the JWT? Is that the case? If so, the JWT would still have the roles from your 'admin' assignment, even after you changed it in FusionAuth.

The solution to that is to use refresh tokens and have your JWTs have a short lifespan (minutes).

Should the frontends be talking to FusionAuth directly?

I'm not sure I understand this question. There are a couple of different aspects, but I'd refer you to this documentation on the variety of login flows available. I'd pick a flow that makes the most sense for you.

At the very least, I'd say that your monolith should provide the oauth-redirect redirect endpoint, which catches the authorization code and exchanges it for a token. After that, you can store the token in the session on the monolith or push it down as a secure HTTP only cookie. Either way is fine, they just have different tradeoffs.

tstamadianos

@dan Thank you for your response! I spent some time reading and understanding a lot more about OAuth2 and everything you covered makes sense now.

With regards to our frontend, I read some of the excellent documentation and we're going with the JWT refresh token approach you've described here. It looks like ASP.NET Core doesn't really want to act as an intermediary out-of-the-box, so I'll have to investigate further and maybe write out those methods myself.

If you'd like I can take what I learned and make a pull request on the ASP.NET Core examples repo to demonstrate JWT auth for ASP.NET Core APIs.

Thanks again!

dan

Thanks for offering to create a pull request against the demonstration application!

That would be fantastic!

maciej.wisniowski

Regarding the SPA and proper authentication flow, there are some more things to consider. First, if your SPA is served from the domain that is different from your backend's domain (eg. using Vercel to host SPA frontend) then you'll have issues with cookies between different domains. Another thing is security, specifically CSRF. You'll possibly have to implement some CSRF tokens to handle this. There is a lot of information regarding these topics on the Internet but still it doesn't seem to be very easy to implement. The first link I've found on the topic: https://ideneal.medium.com/securing-authentication-in-a-spa-using-jwt-token-the-coolest-way-ab883bc372b6.
Would be great if FusionAuth docs can also describe these issues (different domains, CSRF).

Because of that it is worth considering if some other flow isn't better - AuthorizationCode + PKCE that doesn't touch the backend at all (no cookies, no CSRF issues, but you have to be careful with XSS). I've implemented a proof of concept React application that uses https://github.com/IdentityModel/oidc-client-js and slightly modified react-oidc (that is a react wrapper to oidce-client-js), and it seems to work nicely with FA for me.