#198 - OIDC public client support needed — incompatible with IdPs that only support confidential clients - adam/gate

therry47 commented

2025-12-09 16:12:29 -06:00

(Migrated from github.com)

Describe your idea for an enhancement:

It would be beneficial for VoidAuth to support public OIDC clients (i.e., clients that do not use a client_secret).
Many modern applications — especially browser-based apps, mobile apps, and desktop clients — are designed as public clients and cannot securely store a secret. Supporting this type of client would significantly improve compatibility with a wide range of identity and authentication ecosystems.

Describe alternatives you've considered:

Public clients are a common part of the OIDC specification, and many applications rely on them by design; avoiding them is generally not feasible.
Workarounds such as proxying the authentication flow or wrapping the client in a confidential backend introduce unnecessary complexity and can create security risks.
Modifying the application to act as a confidential client is not possible when the client runs entirely on the user side (browser, mobile, etc.).

Additional context:

In my specific case, I’m trying to integrate VoidAuth with OpenCloud, whose Web/desktop/mobile clients are public-only according to their documentation:
https://docs.opencloud.eu/docs/next/admin/configuration/authentication-and-user-management/external-idp

Because VoidAuth only supports confidential clients and OpenCloud only supports public clients, integration is currently impossible.
Adding support for public clients would resolve this and improve interoperability with many similar applications.

### Describe your idea for an enhancement: It would be beneficial for VoidAuth to support public OIDC clients (i.e., clients that do not use a client_secret). Many modern applications — especially browser-based apps, mobile apps, and desktop clients — are designed as public clients and cannot securely store a secret. Supporting this type of client would significantly improve compatibility with a wide range of identity and authentication ecosystems. ### Describe alternatives you've considered: - Public clients are a common part of the OIDC specification, and many applications rely on them by design; avoiding them is generally not feasible. - Workarounds such as proxying the authentication flow or wrapping the client in a confidential backend introduce unnecessary complexity and can create security risks. - Modifying the application to act as a confidential client is not possible when the client runs entirely on the user side (browser, mobile, etc.). ### Additional context: In my specific case, I’m trying to integrate VoidAuth with OpenCloud, whose Web/desktop/mobile clients are public-only according to their documentation: https://docs.opencloud.eu/docs/next/admin/configuration/authentication-and-user-management/external-idp Because VoidAuth only supports confidential clients and OpenCloud only supports public clients, integration is currently impossible. Adding support for public clients would resolve this and improve interoperability with many similar applications.

👍 1

notquitenothing commented

2025-12-10 17:16:13 -06:00

(Migrated from github.com)

Hello! Thank you for opening an issue!

Can you try adding the OIDC Client anyways and selecting none for the Token Endpoint Auth Method option? That might work, and if it does I will improve the UI to make that more clear. For the Client Secret just autogenerate one.

Hello! Thank you for opening an issue! Can you try adding the OIDC Client anyways and selecting `none` for the `Token Endpoint Auth Method` option? That might work, and if it does I will improve the UI to make that more clear. For the `Client Secret` just autogenerate one.

therry47 commented

2025-12-10 18:19:29 -06:00

(Migrated from github.com)

Hello — thanks for your reply!

I was unsure this was the right option for public clients because it forced me to provide a client secret. I think in that case the field should not be required and should be disabled (or hidden) for public clients to avoid confusion.

I'll try adding the OIDC Client with Token Endpoint Auth Method set to none and autogenerating a client secret. I'll try this over the weekend if I have the time (and the inclination), and I'll let you know if it works. Thanks again for your response and great project 😊

Hello — thanks for your reply! I was unsure this was the right option for public clients because it forced me to provide a client secret. I think in that case the field should not be required and should be disabled (or hidden) for public clients to avoid confusion. I'll try adding the OIDC Client with Token Endpoint Auth Method set to `none` and autogenerating a client secret. I'll try this over the weekend if I have the time (and the inclination), and I'll let you know if it works. Thanks again for your response and great project 😊

❤️ 1

prometheus-22 commented

2025-12-16 22:40:33 -06:00

(Migrated from github.com)

Adding onto this discussion with Opencloud there is another issue for the mobile apps:

For iOS the redirect is oc://ios.opencloud.eu and Android is oc://android.opencloud.eu

Both give the below error when attempting to create an OIDC client in VoidAuth

redirect_uris for native clients using Custom URI scheme should use reverse domain name based scheme

Opencloud's OIDC implementation is a little obtuse in my opinion, though I suppose it's not the worst I've dealt with...

Adding onto this discussion with Opencloud there is another issue for the mobile apps: For iOS the redirect is `oc://ios.opencloud.eu` and Android is `oc://android.opencloud.eu` Both give the below error when attempting to create an OIDC client in VoidAuth > redirect_uris for native clients using Custom URI scheme should use reverse domain name based scheme Opencloud's OIDC implementation is a little obtuse in my opinion, though I suppose it's not the worst I've dealt with...

notquitenothing commented

2025-12-17 07:10:22 -06:00

(Migrated from github.com)

That is a bummer, that error/requirement (redirect_uris for native clients using Custom URI scheme should use reverse domain name based scheme) is built into the package VoidAuth uses for OIDC flow, node-oidc-provider. There probably isn't much I can do to help with that, my guess is that those custom URI schemes are not fully OIDC compliant but I will do some research

That is a bummer, that error/requirement (`redirect_uris for native clients using Custom URI scheme should use reverse domain name based scheme`) is built into the package VoidAuth uses for OIDC flow, `node-oidc-provider`. There probably isn't much I can do to help with that, my guess is that those custom URI schemes are not fully OIDC compliant but I will do some research

notquitenothing commented

2025-12-17 07:33:59 -06:00

(Migrated from github.com)

After some quick searching it looks like that requirement is based on IETF RFC documents like this one that define the best practices of native app oauth. It is even specified in that same document (here) that providers should reject native app urls that do not use the reverse domain name based scheme. In order to be compliant, the OpenCloud native app OIDC callbacks should instead look like eu.opencloud.ios:///oc, for example Immich uses app.immich:///oauth-callback.

What is actually causing the error is that the scheme of oc://ios.opencloud.eu is oc, and that does not include a dot/period character in it.

After some quick searching it looks like that requirement is based on IETF RFC documents like [this one](https://datatracker.ietf.org/doc/html/rfc8252#section-7.1) that define the best practices of native app oauth. It is even specified in that same document [(here)](https://datatracker.ietf.org/doc/html/rfc8252#section-8.4) that providers should reject native app urls that do not use the reverse domain name based scheme. In order to be compliant, the OpenCloud native app OIDC callbacks should instead look like `eu.opencloud.ios:///oc`, for example [Immich](https://docs.immich.app/administration/oauth/#prerequisites) uses `app.immich:///oauth-callback`. What is actually causing the error is that the scheme of `oc://ios.opencloud.eu` is `oc`, and that does not include a dot/period character in it.

prometheus-22 commented

2025-12-17 12:31:58 -06:00

(Migrated from github.com)

That's what I found as well, hence my previous statement about it being a little obtuse. It's technically out of spec but I guess the other auth providers I've tried just ignore that and let you use it anyway. Just wanted to share for anyone else's awareness.

❤️ 1

notquitenothing commented

2025-12-17 23:33:17 -06:00

(Migrated from github.com)

I am making an update to silence the redirect_uris for native clients using Custom URI scheme should use reverse domain name based scheme error, since it seems to be a best-practices issue just to incentivize app creators in a certain way. Security impacts seem to be mostly centered around proving app ownership in the case of counterfeit apps in app stores

I am making an update to silence the `redirect_uris for native clients using Custom URI scheme should use reverse domain name based scheme` error, since it seems to be a best-practices issue just to incentivize app creators in a certain way. Security impacts seem to be mostly centered around proving app ownership in the case of counterfeit apps in app stores

👍 1

notquitenothing commented

2025-12-18 07:11:24 -06:00

(Migrated from github.com)

Additional support for public OIDC Clients has been released in v1.6.0, but it could probably still use some work. Let me know if the changes work for OpenCloud 😊

Additional support for public OIDC Clients has been released in [v1.6.0](https://github.com/voidauth/voidauth/releases/tag/v1.6.0), but it could probably still use some work. Let me know if the changes work for OpenCloud 😊

🎉 1

prometheus-22 commented

2025-12-18 21:04:49 -06:00

(Migrated from github.com)

I've got OpenCloud web working but I can't quite get the desktop/mobile apps working. The two errors I'm still seeing for desktop/mobile:

oidc-provider:authentication:error { error: 'invalid_request', error_description: 'unsupported prompt value requested' ... } It looks like the prompts being sent are consent & select_account
oidc-provider:error path=/token method=POST error={ error: 'invalid_client', error_description: 'client authentication failed' } detail=the provided authentication mechanism does not match the registered client authentication method I have Auth Method set to None (Public)

The desktop clients also use http://127.0.0.1 with a randomized port number for the redirect URL and it doesn't look like wildcards are supported for redirect URLs. Normally I'd use http://127.0.0.1:* here.

The update to silence the redirect_uris error probably should also be applied to PostLogout URL field since it gives the same message.

I've got OpenCloud web working but I can't quite get the desktop/mobile apps working. The two errors I'm still seeing for desktop/mobile: 1. `oidc-provider:authentication:error { error: 'invalid_request', error_description: 'unsupported prompt value requested' ... }` It looks like the prompts being sent are `consent` & `select_account` 2. `oidc-provider:error path=/token method=POST error={ error: 'invalid_client', error_description: 'client authentication failed' } detail=the provided authentication mechanism does not match the registered client authentication method` I have Auth Method set to `None (Public)` The desktop clients also use `http://127.0.0.1` with a randomized port number for the redirect URL and it doesn't look like wildcards are supported for redirect URLs. Normally I'd use `http://127.0.0.1:*` here. The update to silence the `redirect_uris` error probably should also be applied to PostLogout URL field since it gives the same message.

notquitenothing commented

2025-12-22 12:15:45 -06:00

(Migrated from github.com)

I am planning on adding wildcard support in redirect urls in the next release. Will need to look into how to properly handle un-implemented prompts like select_account.

If you need to set the Auth Method to None (Public) but then get that invalid_client error, that seems to me like you might just need two OIDC Clients (one for public, and one that seems to be using a Client Secret).

I am planning on adding wildcard support in redirect urls in the next release. Will need to look into how to properly handle un-implemented prompts like `select_account`. If you need to set the Auth Method to `None (Public)` but then get that `invalid_client` error, that seems to me like you might just need two OIDC Clients (one for public, and one that seems to be using a Client Secret).

prometheus-22 commented

2025-12-22 19:28:21 -06:00

(Migrated from github.com)

I'm not sure what's up with invalid_client since all of the below is supposed to be true. It also used to work on my previous IDP but since testing the various clients with VoidAuth and then moving things back, only Web is working there too.

All clients provided by OpenCloud (Web, Desktop, Android, and iOS), are implemented as public clients using the authorization code flow with PKCE. Therefore the IDP needs to support this flow.

All clients, except the Web client, use predefined client IDs. Therefore the IDP needs to be able to create clients with predefined IDs.

All clients, except the Web client, use a hardcoded list of scopes they request from the IDP. As certain features of OpenCloud (especially the automatic role assignment) rely on specific claims being present in the access token or the UserInfo response, the IDP needs to be able to provide additional claims in the Tokens even if the client does not explicitly request them via scopes.

I'm not sure what's up with `invalid_client` since all of the below is supposed to be true. It also used to work on my previous IDP but since testing the various clients with VoidAuth and then moving things back, only Web is working there too. > All clients provided by OpenCloud (Web, Desktop, Android, and iOS), are implemented as public clients using the authorization code flow with PKCE. Therefore the IDP needs to support this flow. > All clients, except the Web client, use predefined client IDs. Therefore the IDP needs to be able to create clients with predefined IDs. > All clients, except the Web client, use a hardcoded list of scopes they request from the IDP. As certain features of OpenCloud (especially the automatic role assignment) rely on specific claims being present in the access token or the UserInfo response, the IDP needs to be able to provide additional claims in the Tokens even if the client does not explicitly request them via scopes.

DodoLeDev commented

2026-02-15 18:40:28 -06:00

(Migrated from github.com)

Hii!
I have been trying to setup OpenCloud with VoidAuth too, and faced another problem: I faced this error, which requires the settings PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none on the OpenCloud side.

This means that VoidAuth does not send JWT-encrypted responses to OpenCloud in Public Client mode? Is it a feature of the OIDC standard?

BTW a bit of doc about how to setup VoidAuth with OpenCloud would be awesome 😄

Hii! I have been trying to setup OpenCloud with VoidAuth too, and faced another problem: I faced [this error](https://github.com/opencloud-eu/opencloud/issues/1578), which requires the settings `PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none` on the OpenCloud side. This means that VoidAuth does not send JWT-encrypted responses to OpenCloud in Public Client mode? Is it a feature of the OIDC standard? --- _BTW a bit of doc about how to setup VoidAuth with OpenCloud would be awesome_ 😄

Glimpse5153 commented

2026-03-15 06:01:31 -05:00

(Migrated from github.com)

Hello, public clients seems to work, but I have to use the id token because the access token seems to be an opaque token and not a jwt token? As far as I know this should not be the case, but correct me if I'm wrong?

notquitenothing commented

2026-03-15 14:22:46 -05:00

(Migrated from github.com)

Interesting, looks like OIDC does support opaque and JWT access tokens (good docs without having to read spec -> https://auth0.com/docs/secure/tokens/access-tokens), but I am still working out if this is something that node-oidc-provider supports. My guess is that it probably is supported, and is probably behind a feature flag (maybe this one -> https://github.com/panva/node-oidc-provider/tree/main/docs#featuresjwtresponsemodes)

Interesting, looks like OIDC does support opaque and JWT access tokens (good docs without having to read spec -> https://auth0.com/docs/secure/tokens/access-tokens), but I am still working out if this is something that `node-oidc-provider` supports. My guess is that it probably is supported, and is probably behind a feature flag (maybe this one -> https://github.com/panva/node-oidc-provider/tree/main/docs#featuresjwtresponsemodes)

Glimpse5153 commented

2026-03-16 03:54:45 -05:00

(Migrated from github.com)

You are indeed correct, in the case of opaque token, the api has to do an additional introspection. So for me this is fine, but perhaps it's possible to have a choice for the access_token to be jwt or opaque? Which is a feature ofcourse, no pressure there from me. Thanks for the app already!

Edit: the .well-known/openid-configuration response does not specify an introspection endpoint at this moment, so I think the returned opaque token can't be used?

You are indeed correct, in the case of opaque token, the api has to do an additional introspection. So for me this is fine, but perhaps it's possible to have a choice for the access_token to be jwt or opaque? Which is a feature ofcourse, no pressure there from me. Thanks for the app already! Edit: the .well-known/openid-configuration response does not specify an introspection endpoint at this moment, so I think the returned opaque token can't be used?

Rows
Columns

OIDC public client support needed — incompatible with IdPs that only support confidential clients #198

Describe your idea for an enhancement:

Describe alternatives you've considered:

Additional context: