Custom OIDC is undebuggable about rustdesk-server-pro HOT 14 CLOSED

@fufesou

from rustdesk-server-pro.

@dasJ Hi, thanks for your feedback.

We will get the username based on this priority.

There's a restriction of the username that it should be at least 4 characters.

@rustdesk Maybe we can

1. Combine the username and the platform, if we can get the username, while the username is less than 4 characters.
2. Generate a random username if we can not get the username.

from rustdesk-server-pro.

Remove lenght limit for oidc.

from rustdesk-server-pro.

So spent the last hour debugging and we found the issue.

Our oidc issuer does not return, name/username/preferred_username in the IdToken but rather only returns these values for a UserInfo request.
We monitored the requests sent from rustdesk and noticed that a userinfo request was never sent.
So the length limit error is shown because the values are never present, resulting in a value smaller than 4.
I've looked this up in the core spec and realized that it is not required to have these claims present on IdTokens, so in my opinion you can't rely that these values are present and need to send an additional UserInfo request.

https://openid.net/specs/openid-connect-core-1_0.html#IDToken states what an ID Token must contains and it says to other Claims:

ID Tokens MAY contain other Claims. Any Claims used that are not understood MUST be ignored. See Sections 3.1.3.6, 3.3.2.11, 5.1, and 7.4 for additional Claims defined by this specification.

So it is not required to have the name/... claims in the IdToken response.

Furthermore it states in https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims that profile scope values are returned for the UserInfo Endpoint unless you use response_type=id_token. You guys use response_type=code, so you cant depend that these values are present and if they aren't you have to send an additional request.

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.

If you guys use https://github.com/ramosbugs/openidconnect-rs you can just follow the gitlab exxample on how to send this additional request: https://github.com/ramosbugs/openidconnect-rs/blob/main/examples/gitlab.rs#L186

Hope this helps on finding a solution for this

from rustdesk-server-pro.

Thanks for your kindly help.

If you guys use https://github.com/ramosbugs/openidconnect-rs

Yes, we use openidconnect-rs, and we've already added the "profile" scope.

The "profile" scope is applyed in the step of Step 4, which you can't see.

The "End User" can only see Step 2.

from rustdesk-server-pro.

We may try to use the email username or the "sub" field if no username can be fetched.

from rustdesk-server-pro.

The problem is, step 4 doesnt happen. I know that a Enduser can't see that request but someone with access to the reverseproxy logs at least can see what routes are being it and we see the authorize and token request but i dont see any userinfo requests.

I tested this against the oidc issuer with the example provided by the library and it doesnt return a name, ..., etc in the IdToken Response. But its contained in the UserInfo response. With that example i btw see all 3 requests authorize, token as well as userinfo this is not the case when using rustdesk, so i have to assume that you currently dont send that userinfo request and only take the claims from the IdToken or that we somehow hit a edge case where the userinfo request isn't send

from rustdesk-server-pro.

The "The name is too short, at least 4 characters" message indicates that the exchange_code is already called.

Which oidc provider did you use? Maybe it does not return the standard fields.

from rustdesk-server-pro.

yeah exactly that what i am saying. You do the exchange_code request, and we see that request on reverse proxy level, but the exchange_code request doesn't actually return the name and preferred_username. It is not required by the the standard and our oidc doesnt do that. The exchange_code request returns the idtoken, but neither name nor preferred_username need to be present there. You guys are missing the userinfo request which actually returns all claims. you can't expect name, ... to be part of the exchange_code response as shown by your screenshot posted above and this part

ID Tokens MAY contain other Claims. Any Claims used that are not understood MUST be ignored. See Sections 3.1.3.6, 3.3.2.11, 5.1, and 7.4 for additional Claims defined by this specification.

https://github.com/ramosbugs/openidconnect-rs/blob/414eb35419f84ab370c0d9acc3af72d72b67462c/examples/gitlab.rs#L186-L187 is the request you are missing

from rustdesk-server-pro.

It works with the example, idont know what i should say more other than post this screenshot i.g.

i redacted a ton of personal data but i think its clear that data isn't there on the token response but its present for the userinfo response and based on my understanding of the oidc standard this response seems compliant with the standard

from rustdesk-server-pro.

Thanks very much for pointing out the problem.

I just thought the standard claims will be returned by id token claims.

Anyway, I'll try to read the standard claims from both the id token claims and the userinfo claims.

from rustdesk-server-pro.

nice, that what i tried to explain to you that its only required that its part of the IdToken when response_type=id_token which isn't the case for rustdesk, see 5.4 as mentioned above.

Thanks for looking into it :D

from rustdesk-server-pro.

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.

Section 5.4
I see this description, but to honest, I'm still confused.

"when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token."

It seems to state that the "Claims" are in the "ID Token" if response_type=id_token.

But it does not matter, I've already read the "Claims" from both the "ID Token Claims" and the "UserInfo Claims".

Anyway, thank you again for your kind help.

from rustdesk-server-pro.

1.1.10

from rustdesk-server-pro.