Custom OIDC default scopes

[BatisteDONDOGLIO]

It seems RustDesk Server Pro requires the "offline_access" scope by default for custom OIDC setups without any control over it.

My OIDC provider (Authelia) config does not provide "offline_access" as a scope for RustDesk Server Pro.

Sure, I could modify my provider config to add it, but I would prefer to have a good use case for it, and retain control over this setting, by being able to configure it on the OIDC client side, meaning RustDesk Server Pro.

Right now, the custom OIDC provider is forced to provide this scope as it's what RustDesk Server Pro seems to require by default and we can't configure it from the Web Console.

Why is this scope required? Is it absolutely mandatory for RustDesk Server Pro to work correctly? It doesn't seem necessary, but I could be missing something.

[fufesou]

My OIDC provider (Authelia) config does not provide "offline_access" as a scope for RustDesk Server Pro.

The OIDC provider's lack of offline_access scope support is acceptable.

The server will verify the OIDC provider's capability (scopes_supported) before proceeding.

Does the server attempt to request the scope regardless of provider support?

Why is this scope required? Is it absolutely mandatory for RustDesk Server Pro to work correctly? It doesn't seem necessary, but I could be missing something.

This was required in earlier versions, but recent updates have made it unnecessary. I will attempt to remove it.

[BatisteDONDOGLIO]

Thank you for your reply!

Actually, after reading your reply and further investigating, I checked my Authelia's /.well-known/openid-configuration and offline_access appears under scopes_supported even tho I don't have it set explicitely as a scope for the RustDesk OIDC client config, or anywhere else in my config, for that matter... So I'm not sure if this is the default Authelia behavior or a bug (I'll investigate this separately).

Regardless, if the scope isn't manually set under the OIDC client for RustDesk (in Authelia's configuration), Authelia RustDesk instantly returns:

Failed to deserialize query string: missing field `code

The callback URL shows:

https://rustdesk.domain.org/api/oidc/callback?error=invalid_scope&error_description=The+requested+scope+is+invalid%2C+unknown%2C+or+malformed.+The+OAuth+2.0+Client+is+not+allowed+to+request+scope+%27offline_access%27.&iss=https%3A%2F%2Fauth.domain.org&state=XwetKsL18bKqntcmczDQBg

I think it would still be relevant to stick to the bare minimum required in terms of scopes requested by RustDesk (openid profile email maybe?) and resort to the Extra claims option to explicitely request offline_access should it be necessary in some configurations.

What do you think?

[fufesou]

I think it would still be relevant to stick to the bare minimum required in terms of scopes requested by RustDesk (openid profile email maybe?)

Agree.

Only these fields will be included as built-in scopes in the next release.

[BatisteDONDOGLIO]

So I'm not sure if this is the default Authelia behavior or a bug (I'll investigate this separately).

Now that I think about it, I believe this is the normal behavior, because Authelia advertises all supported scopes at the provider level, not only the scopes actively used or allowed for any individual clients. So the discovery document describes the capabilities of the server, not the configuration of each client. If my understanding of OIDC is correct.

[fufesou]

Failed to deserialize query string: missing field `code

Have you authorized yet?

code is required only after the authorization.

https://openid.net/specs/openid-connect-core-1_0.html

RustDesk should return the code field, because many OIDC providers are tested.

[BatisteDONDOGLIO]

Hello,

I believe this error message stems from a little "loophole" between Authelia and RustDesk.

Since RustDesk explicitly requests the offline_access scope, Authelia forces the consent prompt for the authorization process everytime authentication is made. This behavior is described in the Authelia documentation:

The following specific and intentional limitations exist:

1. The Authorization Code Flow will require explicit consent if a Refresh Token will be granted to the relying party (i.e. if the client is authorized to request and requests the offline_access or offline scopes).

   The specific requirement is that a Refresh Token must not be issued if consent is not requested however the implication is that explicit consent is required for Refresh Tokens. In the future we will adjust this so the Authorization Code Flow will not mint and grant a Refresh Token unless the relying party explicitly requests consent, with an option to automatically require explicit consent instead of silently ignoring the request for a Refresh Token.

2. If the client requests the user is prompted to provide consent, the mode will automatically be explicit regardless of client registration configuration.

3. If the client requests the user is prompted to login again, then the mode will either automatically be explicit or the flow may also result in a failure that returns an error to the client, regardless of the client registration configuration.

So, since the authentication fails due to RustDesk explicitly requesting the offline_access scope, and Authelia OIDC's configuration for RustDesk is not providing the offline_access scope, Authelia RustDesk returns the Failed to deserialize query string: missing field `code error page, as it's unable to proceed any further, onto the actual authorization process. That is because Authelia stops the OIDC authentication at this step and refuses to continue.

The Authelia URL does give us the hint, and it is the same thing I see under the Authelia logs:

time="2025-12-04T15:52:46+01:00" level=error msg="Authorization Request failed with error: The requested scope is invalid, unknown, or malformed. The OAuth 2.0 Client is not allowed to request scope 'offline_access'." method=GET path=/api/oidc/authorization remote_ip=XXX.XXX.XXX.XXX

That is how I figured out that RustDesk was requesting that scope without any control over this behavior.

For reference, here's my RustDesk OIDC config:

And here is my Authelia OIDC config:

clients:
    # RustDesk OIDC
    - client_id: '[REDACTED]' # Generated with: authelia crypto rand --length 72 --charset rfc3986
      client_name: "RustDesk Server Pro"
      client_secret: "[REDACTED]" # Generated with: authelia crypto hash generate pbkdf2 --variant sha512 --random --random.length 72 --random.charset rfc3986
      require_pkce: true
      pkce_challenge_method: 'S256'
      redirect_uris:
        - https://rustdesk.domain.org/api/oidc/callback
      scopes:
        - openid
        - profile
        - email
        #- offline_access <-- Works as a workaround if uncommented, as this will allow RustDesk to request the scope
      response_types:
        - code
      grant_types:
        - 'authorization_code'
      public: false
      access_token_signed_response_alg: 'none'
      userinfo_signed_response_alg: 'none'
      token_endpoint_auth_method: 'client_secret_basic'
      authorization_policy: 'rustdesk_policy'

Hope this helps!

[BatisteDONDOGLIO]

Little erratum from my previous post:

The Failed to deserialize query string: missing field `code error page comes from RustDesk, not Authelia.

But the core of my observations remain the same.

For reference, I also get this same error from RustDesk if for example, the Authelia ACLs are triggered when attempting to authenticate to RustDesk with Authelia, in case a user isn't allowed to, due to my Authelia ACL policies. (I tested this).

Because as I said in my previous post, the authorization phase will (obviously) fail, as Authelia refuses to proceed any further than this. And RustDesk is left indicating this error. But the URL containing the return code for the Authelia error is quite informative.

The reason will simply not be about offline_access in this particular case, of course.

I hope this helps clarify.

[fufesou]

@BatisteDONDOGLIO Thanks for the information.

But the URL containing the return code for the Authelia error is quite informative.

Sorry, I'm not quite following. Could you explain what issues this might cause?

The reason will simply not be about offline_access in this particular case, of course.

Ultimately, access is being denied by ACL policies, with offline_access acting as the trigger?

Would eliminating offline_access in the upcoming version fix this problem?

[BatisteDONDOGLIO]

Sorry, I'm not quite following. Could you explain what issues this might cause?

Sorry, none. I was just explaining that the issues I was facing (with the offline_access scope, or for example in case of an ACL issue) were visible from the URL itself when RustDesk shows the error. As the Authelia reason for failure is visible in the URL (and the Authelia logs, obivously).

Ultimately, access is being denied by ACL policies, with offline_access acting as the trigger?

My apologies again for the confusion, I just wanted to explain that the behavior of RustDesk returning Failed to deserialize query string: missing field `code was the same, whether it was caused by the offline_access scope or in the example of it being an ACL issue from the provider. Because you asked me #840 (comment) so I was attempting to clarify this behavior.

Ultimately, the RustDesk server will always say Failed to deserialize query string: missing field `code if the provider refuses to continue at this step, no matter if it's a scope issue or an ACL issue, for example.

Would eliminating offline_access in the upcoming version fix this problem?

Ignore my ACL example. It is unrelated.
Eliminating offline_access will however fix the original issue I was explaining:

RustDesk is requesting that scope (unecessarily) without having any control over it, whether the OIDC provider actually allows it or not.

The fix is to make RustDesk Server request only the mandatory scopes openid profile email and not offline_access.
If admins want to request this scope, they can add it to the "Add Extra Scopes" option in RustDesk, and configure their provider to allow it.

I hope it is more clear, sorry about the confusion!