Announcement Announcement Module
No announcement yet.
OAuth - Anonymous Authentication Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • OAuth - Anonymous Authentication

    I have been able to successfully generate a request token but I'm having trouble getting through authorization and on to generating an oauth token.

    When I make a request into authorize, I'm noticing that the token is considered "authorized". I'm a bit confused why it would be doing this:

    org.sprin[email protected]6faeba70: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.sprin[email protected]fffbcba8: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: nwwhtqmrceg2eu08rvw7uust; Granted Authorities: ROLE_ANONYMOUS
    These are my settings

    Basic Auth for the api, which will change to OAuth once I get the access tokens
    	<sec:http create-session="stateless" entry-point-ref="entryPoint">
    		<sec:intercept-url pattern="/api/**" access="IS_AUTHENTICATED_FULLY" requires-channel="https"/>
    		<sec:custom-filter ref="loginFilter" position="FORM_LOGIN_FILTER" />
    		<sec:logout />
    Provider Settings:
      <oauth:provider consumer-details-service-ref="vhConsumerDetailsService"

  • #2
    I should clarify the steps I've taken from the client side. Here's my workflow so far

    1) send oauth headers with signature to /oauth/request_token and get a request token back
    2) send a request token to /oauth/authorize and get treated as authorized because of the AnonymousAuthenticationToken store in the token


    • #3
      The OAuth1 provider support does some quite extreme things to the security filter chain, including silently adding filters (OAuth2 has been refactored to not do this so it is more predictable, in my opinion). The anonymous filter is enabled by default so my guess is that you could just disable it (<anonymous enabled="false"/>) and you would no longer get anonymous tokens. Or if you need anonymous access for other reasons, explicitly add the oauth endpoint URLs as secure patterns (like in the sparklr sample). I'm guessing here because I'm not using the OAuth 1 features much.


      • #4
        Yeah.. I'm slowly picking up on that stuff.

        I thought the OAuth 2 spec was never full adopted? Isn't it totally different protocol with regards to tokens/handshakes etc?

        Anyway, with OAuth 1 I did turn of Anonymous Auth and now things work as I would expect them, however I'm curious how this would even work. When I make a request to /oauth/authorize and I'm not logged in it should redirect to the "user-approval-url" and this page would require login and thus redirect to the login page. With all this redirecting, how does the reqestToken not get lost? Isn't the end goal to send the user back through /oauth/authorize with the request token whiled authenticated so that the request can be approved.


        • #5
          Yes, OAuth 2 is different. No, it is not in any way officially unadopted (that I know of), in fact it is pretty common these days and OAuth 1.0a is looking like a legacy spec (my opinion).

          The answer to your other question is that the requestToken is stored in between requests. Spring Security has a strategy interface for the things it stores natively (SecurityContextRepository), Spring MVC has a SessionAttributeStore, and Spring Security OAuth adds some more, for storing data with different validity periods than the session in general (although not always). The OAuth 1.0a provider uses OAuthProviderTokenServices, for instance.


          • #6
            I've seen the TokenServices and that is kind of the crux of my confusion. If order to use the token service you need the token value to lookup all the pertinent information.

            If you send a request to oauth/authorize and your aren't logged in then you are going to get bounce to the loggin page and your "requestToken" parameter is going to get lost. This is especially compounded when you are bouncing from one load balancer to the next.


            • #7
              Let's leave load balancers out of it for now - Spring Security generally requires them to use sticky sessions unless you provide your own persistence in one form or another. Does it not work, or are you just curious about how it works?


              • #8
                Prior to adding OAuth I had Spring Security setup for BASIC auth and it was not generating sessions, so that I could be stateless and not worry about adding session overhead on every request.

                I couldn't get OAuth token authentication filter to work without sessions so I decided to roll my own for that. I just decided to call your libraries from my end point. So far it is all working nicely. I need to do some ore testing.

                My implementations for the services (none, token, etc) use s3 for storage rather than memory.


                • #9
                  Stateless is usually fine for resource servers (like the one that you would have use basic auth for). The token provider needs some state to manage the interaction with the user (if any). In my opinion HttpSession should be the default for that, and it is in OAuth2, but quite possibly not in OAuth1 at present. In any case there will be a strategy for the storage in case you need to scale the token provider (but that would be quite unusual in my experience, since the heavy lifting is usually done by resource servers and clients should store tokens locally).


                  • #10
                    What do you typically do for synchronizing your session across multiple machines? Or do you not worry about folks getting logged out on a server crash?


                    • #11
                      I don't actually currently work on any systems where the authorization gets enough traffic to warrant scaling it out at all. If I did I wouldn't worry about users being logged out of the authorization server (the only state in that session is the authentication, and it can easily be regenerated by prompting the user to re-authenticate). Beyond that, there are plenty of choices for session replication, none of which is really specific to OAuth, and all of which come with their own issues.