@cthos

@cthos said in Tenant Issuer configuration might not follow the OIDC specification:

I'm not sure if this qualifies as a bug or a documentation issue (or neither), but there's a potential problem with the advice when setting up a tenant.

Under the tenant settings, you set the token issuer - and it advises you to use the FQDN of your domain. The example given is "fusionauth.io". This issuer winds up in the OIDC Autodiscovery config and I believe the "iss" field of the ID Token. So, if you set it to "fusionauth.io" you'll wind up with this:

{ ... "issuer" : "fusionauth.io", }

Issuer, according to the spec (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata fnaf)

, must include the scheme:

REQUIRED. URL using the https scheme with no query or fragment components that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.

So, that breaks some OIDC Clients rhat strictly adhere to the spec (I tried it with npm's openid-client but there are likely others).

The spec for the "iss" stanza of ID tokens also needs the scheme: https://openid.net/specs/openid-connect-core-1_0.html#IDToken

The current documentation mentions FQDN (Fully Qualified Domain Name) without explicitly stating the need for a scheme. This could lead to misconfigurations if users are unaware that the issuer should include the scheme. It would be beneficial to update the documentation to clarify that the issuer must include both the scheme and the tenant ID. This could help prevent common setup issues.

@peanutsunless glad this was useful for you!

@mark-robustelli thanks for clarifying!

@dan Yes, it works as temporary solution. Thanks!

Personally cannot help you much since I have not deployed my monorepo on a server to see how FusionAuth behaves 😓 but I think it would be easier for others to assist you and understand it if you could share a reproducible repo or something of that sort.

@yuriy-barvenko Performance tweaking can be tricky. It really depends on what your goals are. If you create indexes to improve searching things, it could slow other things down like the login. It may also depend on which database you are using. What DB are you using? What is the purpose of the information you are trying to get? Does it have to be real time? Are there alternatives like data dumps that you could use? Also, you say "the response times are significantly higher than expected." What is this based on? How many users and roles do you have in the system and what is the expected response time? What is the requirement for response time vs what is expected?

I have similar issue with MySql 5.7 and create a issue report here : https://github.com/FusionAuth/fusionauth-issues/issues/2658

Apparently it seem there is typing error in Sql query that miss the table name but use the alias only and hence the error.

@elliotdickison Thanks for posting!

I shared this internally.

Regarding your first point, I agree a table would of MAU/$ would be helpful.

Regarding your second point, really appreciate that (and the feature suggestions/bug reports you make!). We discuss features and pricing pretty regularly, and I'll surface this comment next time we do so.

The suggestions you gave are not very atomic. We have many users with spotty network connections, so we're trying to stick here with 1 API call for registrations.

I hear you. I think we already have some open issues about this, but if you'd like to file an issue outlining your preferred workflow, that'd be great.

The key is not being used on the JWT tab.

@brad Hmm. Thanks for the feedback. Seems like it should have worked.

If you feel like it, please log an issue on our GH issues list: https://github.com/FusionAuth/fusionauth-issues/issues/ with as much detail as you would like. Feel free to reference this issue.

Hello,

It's been a while.

Is it something that can be planned in future?

@jacksontrevan - Let me start of by saying I am not very familiar with React applications. However, thinking about typical application flow, What would happen if the user was already logged in? Can't you get the login screen by just directing them to a secured page vs a "landing page"?

@yves

I'd be interested to see if the same issue occurs on the latest version of FusionAuth. There's 4-5 mentions of Elasticsearch in the release notes between 1.34.0 and 1.45.3, but none of them appear to address what you are seeing.

As mentioned above, also searching directly via id for example fails.

Sorry, I missed that. Are you saying when you search using the ids method (described here under the heading Search for Users by Id) it doesn't find these users? Because that search should go directly to the database and not through ES at all.

It's all a bit suboptimal.

Off topic, but please consider adding your voice to this issue which might help with your schema changes.

@yves

I guess I'm struggling to understand how FusionAuth internally saves the user data. Is this unstructured (e.g. JSON) inside the relational database?

You can examine the database schema FusionAuth uses here: https://fusionauth.io/docs/v1/tech/installation-guide/fusionauth-app#advanced-installation

I guess I can't give this more structure, e.g. defining data types, and so on?

The structure for the .data fields is implicit. This means that you can define the schema by creating a value. So if I set user.data.isPremium to true, then ES will understand that user.data.isPremium is of type boolean.

A couple of notes:

if you change the datatype across users, ES will get confused. Here's docs on how to deal with that: https://fusionauth.io/docs/v1/tech/admin-guide/troubleshooting#mapperparsingexception there's an open issue for allowing schema enforcement. Please upvote it or add other feedback using the PATCH method for arrays in the user.data field is a bit fragile. Here's docs on how to choose this method correctly: https://fusionauth.io/docs/v1/tech/apis/#the-patch-http-method

I guess there's also no "direct" access to the user data via an API? At least I didn't find anything.

You can update, patch or remove values from the user.data field using the normal user APIs. Or did I misunderstand your question?

@hershellasagna Other than server error, I got it resolved. I'm now able to login without issues. In the end it was my on-line server set-up. I thought my SSL certificate was set-up but it wasn't. Once it was, it starting working. Thanks again for replying, it definitely got me going in the right direction!!

That was the same things happens with me.