Spring Security OAuth
  1. Spring Security OAuth
  2. SECOAUTH-237

Use of custom custom authorization-endpoint-url can cause infinite redirect

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 1.0.0.M6
    • Fix Version/s: None
    • Component/s: OAuth 2
    • Labels:
      None

      Description

      In certain circumstances, an infinite loop can occur when forwarding the user from the initial Authorization Endpoint authorize method to the user approval page, when using the default user approval page url of "forward:/oauth/approve_access". This url, "/oauth/approve_access", is bound to our own custom controller. We are supplying custom authorization-endpoint-url and token-endpoint-url properties and have configured the required web.xml oauth2EndpointUrlFilter as mentioned in the documentation. This is using the authorization code flow, with the built in authorization and token endpoint classes.

      To replicate the error, one visits the custom AuthorizationEndpoint url. The first time here in a browser session, the user is prompted to log in, and is redirected to the appropriate user approval page. This is handled as expected by the custom controller. The user clicks the approve button and is redirected to the registered redirect url, as expected.

      If the user then revisits the authorization url, generally by pasting it into the address bar on the web browser (in our case, Firefox 11), then the server goes into an infinite internal forwarding loop through the authorize method of the AuthorizationEndpoint. This method does return the appropriate ModelAndView object, with the view name set to "forward:/oauth/approve_access". However, something in the processing of this forward request fails and it ends up being mapped back to the authorize method.

      In some repeatable cases, if the user instead uses the back button, then they are prompted again with the user approval page. Clicking approve on this page does allow it to continue and issue a new authorization code.

      If we change user-approval-page url property to "redirect:/oauth/approve_access", leaving everything else the same, the user can then revisit the authorization url and successfully complete the flow. However, pressing the back button now causes a session binding error.

      If we remove the custom authorization-endpoint-url and token-endpoint-url properties, and remove the oauth2EndpointUrlFilter from web.xml, everything works as expected. The user can both revisit the url directly and go back through the session using the back button.

      Therefore, we believe the error to be somewhere in the EndpointValidationFilter class implementation of doFilter.

        Activity

        Hide
        Amanda Anganes added a comment - - edited

        Steps to reproduce:

        1) Change the authorization-server configuration as follows.
        Original code, starting at line 119 of spring-servlet.xml:

        <oauth:authorization-server client-details-service-ref="clientDetails" token-services-ref="tokenServices"
        	user-approval-handler-ref="userApprovalHandler" token-endpoint-url="/token" authorization-endpoint-url="/authorize" 
                user-approval-page="redirect:/oauth/confirm_access">
        	<oauth:authorization-code />
        	<oauth:implicit />
        	<oauth:refresh-token />
        	<oauth:client-credentials />
        	<oauth:password />
        </oauth:authorization-server>
        

        New code, starting at 119:

        <oauth:authorization-server client-details-service-ref="clientDetails" token-services-ref="tokenServices"
        	user-approval-handler-ref="userApprovalHandler" token-endpoint-url="/token" authorization-endpoint-url="/authorize">
        	<oauth:authorization-code />
        	<oauth:implicit />
        	<oauth:refresh-token />
        	<oauth:client-credentials />
        	<oauth:password />
        </oauth:authorization-server>
        

        2) Access the authorization endpoint directly, via /sparklr2-1.0.0.BUILD-SNAPSHOT/authorize?response_type=code&client_id=my-trusted-client&redirect_uri=[insert uri here].
        This brings you to the login page. Login as any user, click "approve" on the user approval page. Now the browser should redirect to your redirect_uri, with an authorization code appended to the URI.

        3) Access the authorization endpoint directly again, via /sparklr2-1.0.0.BUILD-SNAPSHOT/authorize?response_type=code&client_id=my-trusted-client&redirect_uri=[insert uri here].
        This causes the infinite redirect. The browser will not load the user-approval-page, and if you watch the server logs (Tomcat, in our case) you will see the request looping infinitely.

        Show
        Amanda Anganes added a comment - - edited Steps to reproduce: 1) Change the authorization-server configuration as follows. Original code, starting at line 119 of spring-servlet.xml: <oauth:authorization-server client-details-service-ref= "clientDetails" token-services-ref= "tokenServices" user-approval-handler-ref= "userApprovalHandler" token-endpoint-url= "/token" authorization-endpoint-url= "/authorize" user-approval-page= "redirect:/oauth/confirm_access" > <oauth:authorization-code /> <oauth:implicit /> <oauth:refresh-token /> <oauth:client-credentials /> <oauth:password /> </oauth:authorization-server> New code, starting at 119: <oauth:authorization-server client-details-service-ref= "clientDetails" token-services-ref= "tokenServices" user-approval-handler-ref= "userApprovalHandler" token-endpoint-url= "/token" authorization-endpoint-url= "/authorize" > <oauth:authorization-code /> <oauth:implicit /> <oauth:refresh-token /> <oauth:client-credentials /> <oauth:password /> </oauth:authorization-server> 2) Access the authorization endpoint directly , via /sparklr2-1.0.0.BUILD-SNAPSHOT/authorize?response_type=code&client_id=my-trusted-client&redirect_uri= [insert uri here] . This brings you to the login page. Login as any user, click "approve" on the user approval page. Now the browser should redirect to your redirect_uri, with an authorization code appended to the URI. 3) Access the authorization endpoint directly again, via /sparklr2-1.0.0.BUILD-SNAPSHOT/authorize?response_type=code&client_id=my-trusted-client&redirect_uri= [insert uri here] . This causes the infinite redirect. The browser will not load the user-approval-page, and if you watch the server logs (Tomcat, in our case) you will see the request looping infinitely.
        Hide
        Amanda Anganes added a comment -

        Dave, did my instructions clear things up for you? Let me know if you still can't reproduce the bug.

        Show
        Amanda Anganes added a comment - Dave, did my instructions clear things up for you? Let me know if you still can't reproduce the bug.
        Hide
        Dave Syer added a comment -

        Thanks. Yes I can reproduce the loop by pasting those urls into my browser. It's not a very realistic scenario, and when I paste the URL from an actual successful session instead of yours, it works (or rather I get an error warning me about CSRF, which seems sensible). I'll have a look at why the loop is happening anyway and see if I can fix it.

        Show
        Dave Syer added a comment - Thanks. Yes I can reproduce the loop by pasting those urls into my browser. It's not a very realistic scenario, and when I paste the URL from an actual successful session instead of yours, it works (or rather I get an error warning me about CSRF, which seems sensible). I'll have a look at why the loop is happening anyway and see if I can fix it.
        Hide
        Dave Syer added a comment -

        I think I fixed this. Please try it out and let me know if you see any problems.

        Show
        Dave Syer added a comment - I think I fixed this. Please try it out and let me know if you see any problems.
        Hide
        Amanda Anganes added a comment -

        Thanks, that does fix the bug. Thanks for taking care of the issue.

        Show
        Amanda Anganes added a comment - Thanks, that does fix the bug. Thanks for taking care of the issue.

          People

          • Assignee:
            Dave Syer
            Reporter:
            Amanda Anganes
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: