Access token as part of a response when using JavaScript client

[iv.hristov]

Hi guys,

I have a question about the jso.js JavaScript client implementation and server-side token provider. Is it possible to have all OAuth2 token access details as part of a response and not as URL parameters? I guess I have to provide a custom filter for that but for the moment I don't see which one exactly. I would like to avoid redirecting the (JavaScript) client request and simply provide the next token value in the response.

Thanks in advance!

Ivan

[Dave Syer]

You mean URL fragments (not URL parameters)?

I don't think there's anything stopping a JavaScript client from using the authorization code grant type. Haven't tried it myself, and it might not be supported by the library you are using. But that might be the easiest way to get the token in the response body - use the token endpoint.

If you want a server-side solution you need to look at the AuthorizationEnpoint. If you register your own implementation with a @RequestMapping for /oauth/authorize it should take precedence over the framework one, so that would be the place to start probably.

[iv.hristov]

Hi Dave,

As a JavaScript client I'm using the oajax implementation found in jso.js on spring-security-oauth git repo. I don't see how to specify using authorization code grant type in the client. Do you know of any other JavaScript client implementations?

Thanks for the hint about the /oauth/authorize precedence. In deed, I was just pondering how to hook-in the AuthorizationEndpoint.

As for the URL, I mean the URL parameters separated by ampersands:
&access_token=ad12bea2-6d14-480f-820c-56e811aa8861&token_type=bearer&state=7f522c50-4392-450a-83ff-9463ef2ea566&expires_in=37179

which are appended to the redirect URL. What do you mean by URL fragments? I didn't see any # fragments being added to the URL.

[Dave Syer]

For an implicit grant there should be a fragment separator. Are you sure it's not there?

I don't know of any fully-baked JavaScipt libraries. Scott Andrews was working on something but he may have been distracted. Ping him on twitter @scothis.

[iv.hristov]

I have a fragment separator in my redirect_uri (as part of my target uri), but I can see in the console a DEBUG message from FilterChainProxy where the redirect_uri is well encoded so there are no fragment separators. How should I specify the authorization code grant type when doing the request?

[Dave Syer]

Per the spec you send response_type=token to the authorization endpoint. The JSO library should be doing that work you. Maybe if your redirect already has a fragment there is a bug in the endpoint, but I hope not. What does your client see in the response location header?

[iv.hristov]

Indeed, the JSO does the job with the response_type=token, I can see it in the logs. In the response location header I see:

http://localhost:8080/webapp/#menu&a...pires_in=43199

Looking at the draft version of the standard, I see that the client will always be redirected. So I guess I can't simply initialize my access_token by asking the server to give me all the OAuth2 details in a response body.

What happens once the access token expires? Is the JSO client going to refresh it? On the server-side if I like to tune the token expiration how should I do ti correctly?

[Dave Syer]

I don't know how JSO handles expiry. I assume it grabs a new token (the same flow).

On the server side there are two settings you can configure: a global property of the *TokenServices, plus every client has their own value taht overrides the global setting if used. For more complicated logic you would provide a custom AuthorizationServerTokenServices.