feat: Wildcard support for Allowed Origins and Redirect URIs

[dopry]

Use cases

As an app developer I want to be able to login from netlify, vercel, or cloudflare feature branch preview deployments without needing to specify every domain variation in the origins and redirect_uris.

Current approaches

The wildcard support can be done by implementing a custom application class that overrides the redirect_uri_allowed, origin_allowed, and post_logout_redirect_uri_allowed methods. I feel these use cases are common enough that we should make a better effort to support them out of the box.

Security considerations

https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2 states "The redirection endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3." This is based on https://datatracker.ietf.org/doc/html/rfc6749#section-10.6. 10.6 focuses on who controls the URI.

In my opinion the specification takes 10.6's concerns about control over a URI to an extreme with the absolute-URI requirement. I feel well informed users can craft wildcard domain specifications that will only allow resources under their control. I feel that by ensuring wildcards are only allowed at subdomains and deeper we satisfy the spirit of 10.6 if not the letter of 3.1.2.

Proposed implementation

• allow a * prefix domain on the host portion starting at the third level domain

  valid: https://*.example.com/path
  valid: https://*.netlify.example.com/path
  valid: https://*-project.vercel.app
  invalid: https://*ample.com/path

@n2ygk I'd love your thoughts on this

[n2ygk]

Would you want to use simple wildcard * or a regex for this? In which case .* would replace * in your examples.

Are there RFC/BCP documents that support this concept?

[dopry]

I would stick to simple wildcards with a startswith/endswith check. I don't think regexes add much value in this case relative to the potential complexity and users shooting themselves support issues it could cause.

There are no RFCs specifying wildcard support in this case, but Auth0 supports it. I feel like ensuring things are domain locked (controlled by the domain owner) ensures the intent of the URI restrictions.

https://auth0.com/docs/get-started/applications/wildcards-for-subdomains

[dopry]

https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2 says absolute uris for authorization redirect endpoints.

The underlying intent is to prevent redirect based exfiltration attacks. If the redirect uris are limited to domains/paths controlled by the application owner then I feel the intent is satisfied by the constraints I've proposed for the wildcards.

[dopry]

In the process of working on the wildcards and reviewing the RFCs I rediscovered logout does have a state like login. Given that wildcards in the path segment should be unnecessary since state can be used to tell the app where to go on logout, I've updated the OP to reflect only the wildcard domain support for CIs with branch deployments.