• Home
  • Categories
  • Recent
  • Popular
  • Pricing
  • Contact us
  • Docs
  • Login
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.8k
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 23 Nov 2020, 13:16

    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
    • R
      robotdan
      last edited by 24 Nov 2020, 16:25

      Related GitHub Issue Allow dynamic redirect URI for OAuth.

      1 Reply Last reply Reply Quote 0
      • D
        dan
        last edited by 30 Nov 2020, 03:14

        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

        D 1 Reply Last reply 13 Mar 2023, 22:19 Reply Quote 0
        • D
          dan @dan
          last edited by 13 Mar 2023, 22:19

          @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