Announcement Announcement Module
Collapse
No announcement yet.
Authentication is required to obtain an access token (anonymous not allowed)?? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Authentication is required to obtain an access token (anonymous not allowed)??

    I am working on Spring Security OAuth 2 based on Spark2 and tonr2. Now I have a question about this exception:

    "Authentication is required to obtain an access token (anonymous not allowed)" on

    org.springframework.security.oauth2.client.token.A ccessTokenProviderChain.obtainAccessToken(OAuth2Pr otectedResourceDetails, AccessTokenRequest)

    Code:
    		if (auth instanceof AnonymousAuthenticationToken) {
    			if (!resource.isClientOnly()) {
                     throw new InsufficientAuthenticationException(
                     "Authentication is required to obtain an access token (anonymous not allowed)");
    			}
    		}
    I was wondering why there was such a limitation, cause I just need to let users to login my site with an other website account....

    Any answer will be appreciated.

    Thnx.

  • #2
    Preventing anonymous users from acquiring an access token is a safeguard against what might otherwise be a nasty mistake - if anonymous users are allowed to obtain tokens you could have all your physical users sharing the same token, which is probably not what you intended. You can override the restriction by not enabling anonymous authentication in your filter chain, and then you can use a remote site to grab user details and populate a real unanonymous authentication (e.g. see https://github.com/cloudfoundry/uaa/...ity/uaa/social).

    Comment


    • #3
      Originally posted by Dave Syer View Post
      Preventing anonymous users from acquiring an access token is a safeguard against what might otherwise be a nasty mistake - if anonymous users are allowed to obtain tokens you could have all your physical users sharing the same token, which is probably not what you intended. You can override the restriction by not enabling anonymous authentication in your filter chain, and then you can use a remote site to grab user details and populate a real unanonymous authentication (e.g. see https://github.com/cloudfoundry/uaa/...ity/uaa/social).
      Thnx for your reply.

      I am still not very clear about the "you could have all your physical users sharing the same token".

      Here is my solution for the OAuth 2.0:
      1. Give my client a pair of key-secret, and also the redirect-URL patterns.
      2. They can provide a URL with some arguments for Users, such as "http://localhost:8080/oauth2-server/oauth/authorize?client_id=testClient&redirect_uri=http://localhost:8081/web-app/&response_type=code&scope=read" to get an Authorization code(Users should login and authorize)
      3. With the code in 2, access "​http://localhost:8080/oauth2-server/oauth/token/?redirect_uri=http://localhost:8081/web-app/&client_secret=secret&grant_type=authorization_cod e&client_id=testClient&code=XXXX" to get Access token json
      4. With access token, they can access proteced resources.

      It seems there is no need to let my clients to login since there are some validation in Requiring Access Token. Maybe it's a problem if someone nasty to make a fake request to let users authorize if they can get client-id. Any other disadvantage about my solution?

      Thanks again.

      Comment


      • #4
        Remember this is an issue to do with the client app, not the auth server, so try and see it from the point of view of the cllient. At step 1. there is a user trying to access a protected resource. If you can't idenitify that user then all your users end up with the same access token (the one that the first user obtains using his credentials at the auth server). This is definitely a bad idea.

        Comment


        • #5
          Ahhh, I see....

          We will force users to protect their key-secrets, and if we find there is something abnormal, we can deal with it....

          Thnx for your reply.

          Comment

          Working...
          X