OAuth 2.0 authentication and redirect uri wildcards

Hello,

Is there a way to authorize all uri of a domain (or subdomain) in the OpenId Application whitelist redirect uri ?

Thanks in advance.

@Loic You cannot. RFC-6749 (OAuth 2.0) states that redirect URIs must be absolute:

The redirection endpoint URI MUST be an absolute URI as defined by
[RFC3986] Section 4.3.

Edit: This is security consideration, as it is outlined in the OAuth 2.0 Threat Model:

An authorization server should require all clients to register their
“redirect_uri”, and the “redirect_uri” should be the full URI as
defined in [RFC6749].

2 Likes

I completely agree about the security concern, but from a testing point of view it’s a major blocker.

There are several UI workflows that deploy testing UI builds to somewhat randomly generated host names (usually fitting a known pattern). Look at Zeit now as an example.

None of these workflows work with Okta and this is a major obstacle to sharing testing builds internally.

I should add that Auth0 used to have the same stance as you, but recently the opened this behavior up, with the expected warnings, and it makes the developer workflow much more effective.

In conclusion, yes, it’s a terrible idea to do this in production, but it’s a vitally useful feature to provide in test environments. Please reconsider.

you can add those redirect URIs to the application instance in Okta with API calls. So your automation tool can handle this, though it’s inconvenience for developers, I agree.

1 Like

This is true, but it’s a terrible DX.

It also complicates/breaks our automation. We use terraform to manage all of the Okta configuration so having random builds wanting to change the redirect_uri really breaks our workflow.

While it doesn’t seem like this is likely to change, I want to point out that RFC3986’s definition of an absolute URI allows for * to be part of the absolute URI. Here are the relevant parts of the grammar that allow for it:

   absolute-URI  = scheme ":" hier-part [ "?" query ]
   hier-part     = "//" authority path-abempty
                 / path-absolute
                 / path-rootless
                 / path-empty
   authority     = [ userinfo "@" ] host [ ":" port ]
   host        = IP-literal / IPv4address / reg-name
   reg-name    = *( unreserved / pct-encoded / sub-delims )
   sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="

There is a comment in RFC-6749 that the most common name registry mechanism is DNS, but to be pedantic, there is no comment in the OAuth 2.0 spec that URIs using a hostname (instead of IP address) must be resolvable via DNS.

I completely agree wildcards in the hostname can be problematic, e.g., *.com. However something like *.mydomain.com when a user owns mydomain and all its subdomains seems reasonable assuming * in this case only represents a single subdomain (i.e., cannot include .). The rules Auth0 uses seem to be sensible: Subdomain URL Placeholders

Just closing the loop on this one if anyone stumbles across this, but Okta has implemented wildcards in subdomains for redirect_uris. More info in our docs here:

  • If wildcard_redirect is DISABLED, all redirect URIs must be absolute URIs and must not include a fragment component. If wildcard_redirect is SUBDOMAIN, then any configured redirect URIs may contain a single * character in the lowest-level domain (for example, https://redirect-*-domain.example.com/oidc/redirect) to act as a wildcard. The wildcard subdomain must have at least one subdomain between it and the top level domain.
  • The wildcard can match any valid hostname characters, but can’t span more than one domain. For example, if https://redirect-*-domain.example.com/oidc/redirect is configured as a redirect URI, then https://redirect-1-domain.example.com/oidc/redirect and https://redirect-sub-domain.example.com/oidc/redirect match, but https://redirect-1.sub-domain.example.com/oidc/redirect doesn’t match.
  • Only the https URI scheme can use wildcard redirect URIs.

Caution: The use of wildcard subdomains is discouraged as an insecure practice, since it may allow malicious actors to have tokens or authorization codes sent to unexpected or attacker-controlled pages. Exercise great caution if you decide to include a wildcard redirect URI in your configuration.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.