FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    Domain based multi tenant apps, and authorizedRedirectURLs

    Scheduled Pinned Locked Moved
    Comments & Feedback
    3
    4
    9.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      bert.goethals
      last edited by

      Hi,

      I know this request has probably arrives several times a year - in fact I read in the blog - but here is my take on it.

      Wildcards should be allowed in authorizedRedirectURLs. That is to say sub-domain based wildcards should be allowed.

      Our use case: We have a multi tenant application with a single user base. Each client is identified by a domain. in 80% of the cases this a subdomain of the main domain of our application (ex: customer.example.com). Other client have their dedicated domains.

      For this setup it would be ideal if we could set up https://*.example.com/redirect as an entry in authorizedRedirectURLs. I know you think this to be unsafe, I've read it:

      However, allowing such wildcard matching for the redirect URI is a security risk. If the redirect URI matching is flexible, an attacker could redirect a user to an open redirect server controlled by them, and then on to a malicious destination; OWASP further discusses the perils of such open redirect servers. While this would require compromising the request in some fashion, using exact matching for redirect URIs eliminates this risk because the redirect URI is always a known value.

      But I think an exaction fo this should be allowed. The lack of this can create both less safe and broken applications. Let me explain:

      If we want to update authorizedRedirectURLs with the new domain, we could. However as there is no API to add or remove entries from this list, we run the risk that in a high concurrency situation we get in a state where not all URL's are in the list. We must also be aware of the size limits of this list (if there is any).

      An alternative solution would be too redirect to a single endpoint in our control. This endpoint then does the final redirect. However, this is just moving the security problem. Now this endpoint must validate the redirect domain and path.
      There is a good chance that as a developer we might do this poorly or at least worse than FusionAuth could.

      So, to summarise:

      Subdomain wild cards should be allowed in authorizedRedirectURLs to deal with application that use subdomains to identify their clients.

      1 Reply Last reply Reply Quote 0
      • robotdanR
        robotdan
        last edited by

        Related GitHub Issue Allow dynamic redirect URI for OAuth.

        1 Reply Last reply Reply Quote 0
        • danD
          dan
          last edited by

          Thanks for the feedback @bert-goethals !

          Yes, I'd vote on that github issue that @robotdan mentioned.

          However as there is no API to add or remove entries from this list,

          Doesn't this API when combined with the application.oauthConfiguration.authorizedRedirectURLs setting allow you to modify the redirect urls? Does that do what you want? What am I missing?

          --
          FusionAuth - Auth for devs, built by devs.
          https://fusionauth.io

          danD 1 Reply Last reply Reply Quote 0
          • danD
            dan @dan
            last edited by

            @dan This was delivered in 1.43. More details in the release notes: https://fusionauth.io/docs/v1/tech/release-notes#version-1-43-0

            --
            FusionAuth - Auth for devs, built by devs.
            https://fusionauth.io

            1 Reply Last reply Reply Quote 0
            • First post
              Last post