Skip to main content
Question

OAuth 2.0 App workflow is not working when Redirect URI consist of IP address

  • May 23, 2025
  • 5 replies
  • 67 views
C
Forum|alt.badge.img

Hi Team,

We have encountered an issue where the Redirect URI consists of the IP address (e.g. https://10.0.16.0) in the OAuth 2.0 App, then we are getting a 403 Forbidden error upon getting the auth_code using the below URI.

URL to get auth_code where the Redirect URI consists IP address: https://account.box.com/api/oauth2/authorize?response_type=code&client_id=<client_id>&redirect_uri=https://10.0.16.0

However, this works as expected if Redirect URI does not consist IP address (e.g. https://google.com)

URL to get auth_code where the Redirect URI does not consists IP address: https://account.box.com/api/oauth2/authorize?response_type=code&client_id=<client_id>&redirect_uri=https://google.com

We started seeing this issue after the introduction of the "Purpose" field beside the "App Details" section of the "Configuration" tab of the OAuth 2.0 App. We are not sure whether this is the reason for this behavioral issue.

Any help would be highly appreciated. Thank you!

    5 replies

    C
    Forum|alt.badge.img

    Hi Siddharth,

    I'm wondering how are you generating a valid certificate for https://10.0.16.0 ;-) ?

    Any way the official version is that you should be using a valid https:// URI.

    The application configuration will allow you 2 exceptions to use http://, localhost and 127.0.0.1

    For example:

    essX09iVABhWwAFzyCduOGPqw.png

    However I did proceed in testing this use case.

    I have a linux box running at 10.1.1.70, I've generated a self sign certificate, and spin up a simple HTTP server using the self signed server.

    Sample python code as example:

           web_server = HTTPServer(
                (config.callback_hostname, config.callback_port), CallbackServer
            )
            web_server.socket = ssl.wrap_socket(
                web_server.socket,
                # keyfile=config.ssl_keyfile,
                certfile=config.ssl_certfile,
                server_side=True,
            )

    The initial request goes through:

    dnx6Ma86RVJlXa_NWjMWNawEQ.png

    The authorization URL generate was:

    https://account.box.com/api/oauth2/authorize
    ?state=box_csrf_token_X...Q
    &response_type=code
    &client_id=0...c
    &redirect_uri=https%3A%2F%2F10.1.1.70%3A5000%2Fcallback

    And once I login, it's also ok:

    lfuixi-0CBQpniLgqJsWxXAQQ.png

    From this point on, of course the browser goes all crazy, and can't verify the authenticity, however, when I as a user do go through with it, the request reaches the server:

    mqoKdCgBMdFoxyRagk14INuOw.png

    So I wasn't able to replicate your use case.

    I would like to understand in which of these steps are you getting the error?

     

     

    C
    Forum|alt.badge.img
    Hi Rui,
    Thank you for your quick response.
     
    The Redirect URI (https://10.0.16.0) I mentioned in the previous comment does not correspond to any real machine and it is just mentioned as an example.
     
    Please find the below analysis we have with various values of Redirect URI.
     
    qdxZBymaJchJpZZOqipsw5GXg.png
     
    vgr3SPprZDuY_4OvKxmJ8WvWg.png


    zmj2Ds-_ubP4Gjl71f2XpHbkg.png
     
    For Case 1 we are getting 403 Error. However, for Cases 2, 3 and 4 we are able to see the HTML page asking for user consent as shown in the respective images.

    From the above analysis, it seems that whenever we have Redirect URL having an IP address, the exact value of the Redirect URI will not work and only the encoded version would work. However, this is not the case for the Redirect URI having a domain name and it works without encoding the Redirect URI value.

    This is causing the issue in our integration as previously the Redirect URI with IP address was working without the need for URL encoding.

    Is this a behavioral change in using the Redirect URI in OAuth 2.0?
    Please provide your insight for the same.
    Thank you!
    C
    Forum|alt.badge.img

    I see what you mean, and I was able to replicate it.

    I'm not aware of changes in this area, so I'll submit the issue.

    It does make sense to always use URL encoding in this situation, so most likely this change was intentional.

    Even in the SDK's there is a function to generate the authorization URL and it does encode the redirect URI.

    So in the mean time my recommendation would be to use URL encoding.

    Best regards

    C
    Forum|alt.badge.img

    Thanks, Rui.

    Since this was working previously and is not working now. Is this a change made during any release? Can you please point us to the change logs where this change is mentioned?

    C
    Forum|alt.badge.img

    Yes, that is what I'm trying to find out.

    I'm not sure if this was a bug fix or it simply did not make it to the change log.

    Terms of ServiceAccessibility statement