Announcement Announcement Module
Collapse
No announcement yet.
How to get access_token programmatically Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to get access_token programmatically

    I have a mobile application that interacts via a JSON API with the server. When users register on the app, I would like the API to register and authorize user in 1 step instead of 2 seprate calls one to register and the other to /oauth/authorize. Is there a way to programatically authroize and return oauth2 access and refresh tokens from a signup controller?

  • #2
    There are two ways (or three) to get an access token in one call to the auth service, both (all) are defined in the spec. One is the password grant type, which is OK if your authentication scheme is username/password, and the other is the implicit grant type, which can be used to get authentication, approval and an access token in one go. Spring Security OAuth added support for implicit grants last week, and we think that is the best route to take, since it doesn't make any assumptions about the authentication mechanism. But to use it to get an access token in a single call you still need to do some work to intercept the call in a custom filter and make the authentication from your request parameters before the /authorize endpoint sees the request. We will probably add something like that as a filter in the framework eventually, but right now it is all up for discussion (since the spec doesn't define this behaviour, we just think it is useful).

    Comment


    • #3
      Thank you for answering. I am using "username/password authentication scheme" for this. Could you expand a bit more on how to "make the authentication from your request parameters before the /authorize endpoint sees the request"?

      Comment


      • #4
        It depends on your application (nothing to do with OAuth). You can write a filter that intercepts /authorize and grabs username/password from the incoming request, authenticates and sets up the Spring SecurityContext *before* the OAuth2 endpoint gets to process the request. You can't use the regular Spring filter to do that because it will try and do a redirect after successful authentication, but you can use the existing AuthenticationManage that you have configured already.

        Comment


        • #5
          In my use case, user is registering to the service.. posting username/password to a signup controller. The controller validates inputs, creates new user and sets up the Spring SecurityContext authenticating the user. If signup successful, I would like to return access and refresh tokens. The solution I thought of first was to use RestTemplate.postForLocation or Jersey Client to invoke oauth/authorize endpoint from inside signup controller with username/password just created, parse response and return it.
          Is there a better solution?

          Comment


          • #6
            I would say that if you are returning access_tokens from endpoints not defined by the spec, then you can do whatever you like. I misunderstood the original question, though, sorry. You can't really offer a user an access_token without knowing what client it is for. If you have some reasonable way to know that (e.g. there is only one client) then I guess all you need is to call the OAuth2ProviderTokenServices to get your token during the registration.

            Comment


            • #7
              How to get access token as json response in implicit call.What custom filter do I need to add in spring-servlet ?
              As Dave suggested to intercept the call in a custom filter and make the authentication from your request parameters before the /authorize endpoint sees the request.

              Can I override getImplicitGrantResponse() but I am not able to intercept the call.

              Any Solution?

              Comment


              • #8
                On a similar subject, rfc6749, the 'resource owner password credentials grant' shows an example (4.3.2) where username and password is in the body as well as Base64 encoded in the Authorization header (albeit doesn't match the one given in the body details).
                My question is, for basic authentication with OAuth2, why do you need the username and password repeated in the body? 2.3.1 actually points out that including in the body should be avoided so why do they do both in the example?
                eg:
                POST /token HTTP/1.1
                Host: server.example.com
                Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
                Content-Type: application/x-www-form-urlencoded
                grant_type=password&username=johndoe&password=A3ddj3w

                Additionally, regarding the comment on 27/10/2011, for the password grant type, only scope is allowed in addition to the credentials. There is no client_id like there is in the 'authorization code grant' type, so do you mean use scope to identify the client type? Or, are you thinking that you would provide a different access token endpoint specific to each 'password' grant type client?

                Thanks,
                L

                Comment


                • bartpved
                  bartpved commented
                  Editing a comment
                  @lumus - the RFC and the example show that the basic authentication is used for the client credentials, the body for user credentials. That's how I read it at least ;-)
              Working...
              X