Native clients and dynamic registration

[Andrii Deinega]

Redirect URIs for the native clients often include (and use) a randomly assigned port, as an example, http://127.0.0.1:{port}/callback12345 (per RFC 8252).

It might make sense for the specification to recommend using the same placeholder for interoperability reasons between different authorization servers.

[Michael Jones]

It may make sense to say that a port number can be used and to cite RFC 8252. This was discussed on the 28-Aug-23 working group call.

[Tom Jones]

Seems like a good idea, but not clear how it could work - more details needed and it probably isn’t an errata.

[Andrii Deinega]

@Tom Jones , I researched this topic a bit more and what I got is

RFC 8252 tells us

Authorization servers MUST require clients to register their complete
redirect URI (including the path component) and reject authorization
requests that specify a redirect URI that doesn't exactly match the
one that was registered; the exception is loopback redirects, where
an exact match is required except for the port URI component.

This means that if we have a native client with redirect_uri set to http://127.0.0.1:22222/callback then the AS should handle requests with redirect URIs like http://127.0.0.1:33333/callback and http://127.0.0.1:44444/callback, etc.

So, this is where we are. It still worth giving some clarification around those nuances in the spec, or maybe, provide some suggestions. Furthermore, I find the OpenID Connect Dynamic Client Registration spec still to be very confusing on this matter. As an example,

Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname.

While RFC 8252, indicates that

the use of localhost is NOT RECOMMENDED

OAuth 2.1 goes further and indicates

Clients should use loopback IP literals rather than the string localhost

Other than that, you should be able to use both IPv4 and IPv6 loopback interfaces, just like http://127.0.0.1:12345/callback and http://[::1]:12345/callback so these things should be corrected.

I don’t also know why the spec forbids “MUST NOT use localhost as the hostname“ for regular clients, I would say it’s OK to allow them for dev purposes (I saw it).

[Tom Jones]

That doesn't get to the problem. How does the web site securely acquire this address? IE how does it prevent an attacker installed on the phone from acquiring that end point on the phone.

thx ..Tom (mobile)

[Tom Jones]

There are no restrictions on what you can do during development.

Your methods works, I have implemented it. But attacks are not difficult.

thx ..Tom (mobile)

[Michael Jones]

I disagree with the statement:

This means that if we have a native client with redirect_uri set to http://127.0.0.1:22222/callback then the AS should handle requests with redirect URIs like http://127.0.0.1:33333/callback and http://127.0.0.1:44444/callback, etc.

Because http://127.0.0.1:33333/callback does not exactly match the registered redirect_uri value, it MUST NOT be accepted.

[Tom Jones]

Forward to Android I agree with mike

thx ..Tom (mobile)

[Andrii Deinega]

Mike, Tom, definitely, this isn’t something I invented yesterday, let me cite this again

the exception is loopback redirects, where an exact match is required except for the port URI component.

I took this right from RFC 8252 so when you deal with native clients, http://127.0.0.1:33333/callback MUST be a valid redirect_uri.

I personally find lots of confusing things / statements about native clients in this spec, I tried to describe some of them above… and there are others.

[Tom Jones]

I see, well you can correct me Mike, but I believe OIDC is built on OAUTH 1.0 and not OAUTH 2.0. I suspect that RFC 8252 is incorrect as there are several ports that create protocol changes, where some protocols should NOT be treated the same. George: I think that 8252 was intended to apply only to HTTP/s ..tom

[Michael Jones]

https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest says this about the redirect_uri:

This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).

This is a core security feature of the specification and we’re not going to change it.

[Tom Jones]

sounds good to me - ..tom

[Andrii Deinega]

This is a surprising turn of events and yes, I didn’t expect to go down this way. The OpenID Connect Core specification doesn’t allow native clients with their ephemeral ports while it’s a must for RFC 8252 and how these things work in practice to the very best of my knowledge & experience.

The authorization server MUST allow any port to be specified at the
time of the request for loopback IP redirect URIs, to accommodate
clients that obtain an available ephemeral port from the operating
system at the time of the request.

‌

[Tom Jones]

I think you are misreading something. Or do you mean that we just have no way to register an ephemeral port. I would like to see a way to register an ephemeral port, but to date I have not seen one. If you could create one, I would support it. Be the change you want to see in the world ..tom

[Michael Jones]

We discussed this on the 18-Sep-23 working group call. We don't believe that it's in scope to change the redirect_uri matching for native application as an errata action. That could be done in a new specification.

[Michael Jones]

Closing per the discussion in the 18-Sep-23 working group call.