Announcement Announcement Module
No announcement yet.
AuthenticationDetails missing for user authentiation in oauth2 grants Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • AuthenticationDetails missing for user authentiation in oauth2 grants

    If I use spring-security-oauth2 with the "password" grant type, when my Basic Authorization is checked, the authentications "details" object is populated by my authenticationDetailsSource configured the normal way in spring security.

    However, by the time it gets through the ResourceOwnerPasswordTokenGranter, a new Authentication is created which has a null "details" object - it does not use the authenticationDetails determined at the time of Basic authentication nor does it use the authentiatcionDetailsSource to build these details again.

    So by the time it gets to my authentiactionProvider, the original authenticationDetails is lost/null. If my back-end logic depends on these authenticationDetails, is there an appropriate way for me to get at them?

  • #2
    If you mean back-end logic in the Auth Server, perhaps what you need is a TokenEndpointAuthenticationFilter? The ResourceOwnerPasswordTokenGranter shouldn't require this for normal operation, though - it is the client that authenticates with Basic headers, not the user (a.k.a. resource owner) - so I'm not 100% sure what you need.


    • #3
      Sorry for the confusion - to clarify, I do not need the Basic authorization header in my back-end user authentication logic. Rather, I am interested in using some of the authenticationDetails, built from the HTTP request, in the user authentication logic.

      In spring-security (without oauth) I am used to being able to define an AuthenticationDetailsSource which can buildDetails() from the HTTP request: IP address, HTTP headers (not necessarily authentication related), etc. Then in my AuthenticationProvider I can get those details via authentication.getDetails() and factor them into the authentication decision in AuthenticationProvider.additionalAuthenticationChe cks().

      In spring-security-oauth, I have been able to successfully build these details and access them in the clientAuthenticationProvider, but by the time it gets to the userAuthenticationProvider through the ResourceOwnerPasswordTokenGranter, the details have been effectively removed - because there is a new UsernamePasswordAuthenticationToken for which authenticationDetailsSource.buildDetails() has never been called.

      It seems that in spring-security-oauth, for USER authentication the authentication.details is not supported - is that intended? I'm wondering if there is another way to get at the details from the original request, and work with them in my authenticationProvider. I've considered the following:
      - build these details in a filter and store them in a ThreadLocal, accessing them via the ThreadLocal from the userAuthenticationProvider
      - OR, somehow get these details into the AuthorizationRequest.authorizationParameters or .approvalParameters, then implement my own ResourceOwnerPasswordTokenGranter and pass these details through in the Authentication.

      Is there a better, more intended way to access such details from the oauth2 userAuthenticationProvider? Thanks again.


      • #4
        I've noticed that the oauth2 AuthorizationEndpoint, which calls into the token granters, has access to the incoming Authentication via the "principal" parameter to "authorize". Would it be appropriate for this to pass the authentication.details into the token granters? Or it could pass the whole authentication object in case the granters wanted to use it.


        • #5
          Dave, you suggested the TokenEndpointAuthenticationFilter - I'm looking at that and I'm thinking it may address this as well as other issues, but I am unclear on one thing - if you use the TokenEndpointAuthenticationFilter, would you still use a ResourceOwnerCredentialsTokenGranter plugged into the token endpoint - it seems like the TokenEndpointAuthenticationFilter would have already done half the work (running the user credentials through the authenticationManager) and all that would need to be done is to create the access token.

          Can you give me some guidance on what downstream changes need to be made if you use the TokenEndpointAuthenticationFilter?


          • #6
            Here's what I've done, which I hope is right, but seems to be working well:
            - I've placed the TokenEndpointAuthenticationFilter right after the FILTER_SECURITY_INTERCEPTOR
            - For the password grant_type, I've replaced the standard ResourceOwnerCredentialsTokenGranter with one that simply pulls the Authentication from the SecurityContextHolder. In that sense it works a lot like the implicit granter, with the filter doing the actual authentication.