Allow clients to set wildcard redirect_uri values.

[Zegnat]

This came up in a very specific context: a micropub tool that does not in advance know what its redirect_uri is going to be. E.g. @cweiske’s shpub running on a server the user connect to via ssh.

Proposed solution (from chat):

• one solution would be to allow all "redirect_uri" by adding a special tag on the client_id page

• <link rel="redirect_uri" href="*"/>

Basically when the redirect_uri is defined as * you would expect the authorization endpoint to allow any URL as if verified by §4.2.2.

Note that the authorization endpoint may still want to warn the user of having skipped verification. This is really only to allow the client creator to let the authorization endpoint know it should not block the request completely – as is currently recommended by the spec.

[cweiske]

I've added the asterisk redirect URI to http://cweiske.de/shpub.htm

[aaronpk]

Is there a reason you can't use a fixed URL for shpub, like http://0.0.0.0:30000?

I'm leery of allowing arbitrary redirect URIs, although having to explicitly enable that is a little better. It would be a lot better if the client support PKCE when enabling this, since PKCE solves the stolen auth code problem that registering redirect URIs helps with.

[cweiske]

• The IP address cannot be fixed, because users may connect via ssh to a server and run shpub on it. The redirect URI would begin with the server IP address
• The port number can also not be fixed, because shpub tries a port number and increases by one until it finds a port that is not in use. I think a fixed port number would break in some cases, which is why I would not like to have that.

[Zegnat]

I’m leery of allowing arbitrary redirect URIs, although having to explicitly enable that is a little better.

Explicitly triggering it is an important part of this proposal. I should have made that clearer.

In fact, if a wildcard is added as a possibility, would it make sense to upgrade the current SHOULD on blocking requests for non-verified redirect_uri values to a MUST? As all clients who have an issue with that can specify the wildcard? Thus overall increasing the security in client implementations.

It would be a lot better if the client support PKCE when enabling this […]

I agree.

[Zegnat]

@sknebel points out in chat that clients are already able to work with variable redirect URLs by passing the redirect_uri value along to a specially crafted page at client_id. Example:

https://example.org/auth?redirect_uri=https://198.51.100.0/listen
                        &client_id=https://app.example.com/%3Furi%3Dhttps%3A%2F%2F198.51.100.0%2Flisten
                        &…

The problem with this is that the user is “leaking” their redirect_uri to the third-party that is hosting the client identifier URL. For the type of applications discussed here, that will often involve an IP address and an open port.

If a client already knows it is in need of variable redirect URLs, it would be better to express this with an explicit * on their identifier page than working around it. Especially because this will inform the authorization endpoint of the fact a variable redirect URL is used, and special action may be taken there.

Special action could be something like showing different warnings to users, or requiring PKCE.

[Zegnat]

I've added the asterisk redirect URI to http://cweiske.de/shpub.htm

I noticed a problem with this while compiling the Client Information table. href="*" gets treated as a relative URL so the actual redirect URL became http://cweiske.de/*.

So if * becomes part of the standard, we have to be careful to define its use before ever getting to the part where URLs are resolved.

[sknebel]

A possible solution is to allow wildcards as part of valid URLs, e.g. http://*:*/callback, although testing for how URL parsers treat this might be required. (Python's urllib happily parses the above as an absolute URL)

[aaronpk]

This has been resolved in the OAuth working group for some time, and the general consensus is that any sort of wildcard support in redirect URLs opens up attack vectors. One of the possible solutions is a setup stage which can sort of "dynamically register" a redirect URL for the one specific request such as described by the Pushed Authorization Request extension to OAuth, which we could adapt to IndieAuth.