Dynamic Registration redirect_uri ambiguity

[Michael Jones]

@John Bradley brought this to my attention in e-mail:

William found a developer with a interesting take on the registration spec.
They are trying to enforce localhost for custom scheme URI

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

The way I intended that to be parsed was:
Native Clients MUST only register (redirect_uris using custom URI schemes) or (URLs using the http: scheme with localhost as the hostname).

At least this reader is parsing it as:
Native Clients MUST only register (redirect_uris using custom URI schemes or URLs using the http: scheme ) with localhost as the hostname.

The clarification is that either custom URI schemes (com.example.app:/*), or a localhost redirect with http (http://localhost:*/*)) schemes are acceptable redirects for Native Clients – there is no requirement that localhost must be used with a custom URI scheme (in fact such redirects have no host component).

Should we also explicitly mention that the IP literal form in place of localhost is acceptable? i.e. 127.0.0.1 and [::1]?

‌

[Michael Jones]

Discussed on the 14-Aug-23 working group call. Our conclusions were: * We should make the sentence unambiguous. * We should say that custom URI schemes are acceptable. * It doesn't seem worth mentioning IP literal forms in an errata update.

[Andrii Deinega]

Michael, I “parse” this sentence as it was intended

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

I do not mind making it sound clearer.

[Andrii Deinega]

What I find to be a bit strange is that the allowed schema is only, and only http. CAs, especially in managed envs, can issue and provision TLS certificates for localhost with no issues. I have seen a few issues when app / L7 firewalls rewrite http:// to https:// in an HTTP redirect to a native app and that caused quite a lot of trouble.

In general, I think, the AS should allow using https:// for the native clients because the app.loc hostname in https://app.loc:12345/callback can be resolved to 127.0.0.1. I don’t see any issues with that. In the meantime, this nuance is undesirable for the OpenID Connect Dynamic Client Registration specification.

[Vladimir Dzhuvinov]

How is an mobile app that claims an https URL for redirection to be considered - application_type=web or application_type=native ?

[Andrii Deinega]

Vladimir, from the AS standpoint, it should be definitely a native client because this client

1. must implement and use the Proof Key for Code Exchange (PKCE) extension
2. contains some placeholder for a randomly assigned port in its redirect_uri, lets say https://app.loc:{12345}/callback. You have no way of knowing this port in advance, right?

‌

[Andrii Deinega]

Interestingly enough, even though during the call we decided to

It doesn't seem worth mentioning IP literal forms in an errata update.

Section 8.3 Loopback Redirect Considerations of RFC 8252 tells us that

 While redirect URIs using localhost (i.e.,
   "http://localhost:{port}/{path}") function similarly to loopback IP
   redirects described in Section 7.3, the use of localhost is NOT
   RECOMMENDED.  Specifying a redirect URI with the loopback IP literal
   rather than localhost avoids inadvertently listening on network
   interfaces other than the loopback interface.

So, it’s better off to use 127.0.0.1.

[Tom Jones]

I have been using http://127.0.0.1 with OIDC for several years without problem. Not sure why a change is needed. Nor do i understand the need for https. If the local machine is not trusted then this connex is the least of their problems.

[Michael Jones]

I will consider language around numeric loopback addresses such as 127.0.0.1 while creating the PR that addresses the ambiguity cited by @John Bradley .

[Michael Jones]

To be fixed by https://bitbucket.org/openid/connect/pull-requests/620

[Michael Jones]

Fixed #2026 history entry

→ <<cset 1fb7ef70399d>>