[5.0.7] Embedded IdP client registration doesn't allow redirect URI

[AliveDevil]

Describe the bug

When creating a custom client registration using redirect_uri of format "protocol:action", the embedded IdP refuses to cooperate.

Steps to reproduce

Create config/idp.yaml, with

clients:
… (OCIS defaults)
- id: A
  name: Display Name
  trusted: false
  secret: B
  redirect_uris:
  - x-app-action:oauth
  origins: []
  application_type: native

Expected behavior

When logging in with an OAuth client using above values, this should work just fine with the openid-configuration endpoints:

https://ocis.domain/signin/v1/identifier/_/authorize?client_id=A&code_challenge=…&code_challenge_method=S256&redirect_uri=x-app-action:oauth&response_type=code&scope=openid%20email%20offline_access&state=…

When you call the configuration option "redirect_uri" this should accept all URI-types, not just URLs, otherwise rename to redirect_urls, or state, with a warning, that this must be an URL, not a URI.

Actual behavior

Despite a client registration, that looks to be valid (based on the desktop client configuration) the authentication is still not possible.
Responds with

400 invalid_request - invalid or missing redirect_uri

Setup

docker-compose setup, behind reverse proxy - works fine for the desktop client and web interface, but not for custom clients, with embedded IdM and IdP.

Additional context

Changing the redirect uri to a url protocol://action works fine - but the semantic for URLs is a different one from URIs, where URLs are URIs of format protocol://[identity@]authority[:port]/path[?query][#anchor], where authority is oauth is different from using a URI, where the protocol content is arbitrary and application defined (i.e. x-app-action:oauth is semantically different from x-app-action://oauth).

[jvillafanez]

Could you point some official docs where that is a thing? So far, I've only seen docs for custom protocols such as protocol://action, which is what the android and ios clients are doing. However, I haven't seen any mention on app-action:oauth being possible.

[AliveDevil]

Thats the point.
The field is called URI, not URL, thus I expect URIs to work, not just URLs.

[jvillafanez]

I guess it isn't supported, at least for now.
We're using libregraph/lico server behind the scenes, and the error seems to come from https://github.com/libregraph/lico/blob/master/oidc/payload/authentication.go#L335-L337
The app-action:oauth seems to be interpreted as scheme = app-action opaque = oauth , but there is no host, so the check fails.

You can try to open a ticket in https://github.com/libregraph/lico/ in order for them to allow those URIs. Then, us updating the server version should fix the issue.

[rhafer]

I am closing this one. As this is tracked upstream now.