4

I am wondering why OAuth2 spec does not define a JSON response mode to return the access token in the implicit grant flow. Is it because there was no time to agree upon this and spec it? Or does returning an access token in a JSON format open certain security vulnerabilities? If so, it would be interesting to know which (I suspect that returning JSON into malicious script tags could be mitigated by verifying either ContentType or RequestedWith header of the request).

There is a wide range of modern javascript applications with a need to refresh the access token. This is typically needed when permissions for protected resources change often (for example, when certain users are giving permissions to other users for the resources they own). In this case it is necessary to obtain an access token every time a protected resources is accessed.

Currently OAuth2 spec provides 2 response modes: fragment and form post (in a draft). Fragment response requires a redirect which is not friendly to the user. It is also possible though to post a form with method GET into a hidden iframe which would callback to the javascript code that would pass the access token to the parent window. But this is rather hackish approach from the development point of view.

It would be much cleaner to just return the access token in a JSON format via an AJAX request given that it would not compromise security.

dennis
  • 562
  • 6
  • 21

1 Answers1

0

The redirect is critical to guarantee that the access token is delivered to the RP instead of to an attacker in an implicit flow.

If Stack Overflow had a REST API with OAuth2 Implicit Grant that gave the token back in some JSON format then all I would have to do is trick you to go to one of my web pages, then pretend to be the official Stack Overflow client requesting an access token with your session (as you're probably logged in).

The SO server would return (via CORS) a bit of JSON to me with YOUR Access Token and I could then impersonate you and you would be none the wiser.

Now given that you have to do a redirect anyway, one could add parameters in a JSON token and add that in a query parameter. But if you already have to do query / fragment parsing you might just as well get the parameters from the query / fragment instead of also forcing the client to do JSON parsing.

Boy Baukema
  • 2,908
  • 1
  • 27
  • 38
  • Could you please clarify one moment? Let's says SO is our victim and evil.com is the website you tricked the user to visit. When you make a JSON request from evil.com to SO on behalf of the user, you need to send it with credentials (otherwise, the request cookies will not be sent to SO and it will not give back the access token since the request is not authenticated). And when you send the request with credentials, the SO must explicitly whitelist evil.com in its Access-Control-Allowed-Origins. Yes, there are also tricks with embedding ajax call to the – dennis Aug 25 '14 at 09:40
  • Yes, this would mean that evil.com would only be able to get credentials for users that have already given consent to that client (works best with an XSS vuln, some social engineering or a really large user base). A large party like SO is not going to to whitelisting for every API client, they will simply allow all. – Boy Baukema Aug 25 '14 at 14:46
  • No, my point was that evil.com will not be able to get any credentials - when doing a cross-domain ajax request with cookies, SO **must** whitelist evil.com, allowing all does not work. See [this](http://stackoverflow.com/questions/19743396/cors-cannot-use-wildcard-in-access-control-allow-origin-when-credentials-flag-i) for example. If the user gives consent to the evil client, well nothing will help here at all. Social engineering - yes, but that's a different vector of an attack. So I am still not quite sure what the vulnerability is :) – dennis Aug 26 '14 at 20:10
  • Now when I think about it, it basically boils down to the following question: can you steal private data from a website using cookie-based authorization using CSRF? Yes, you can tamper with the user by sending him to //so.com/account/delete when he clicks on the pictures and stuff like that, but you can't really read the user's private data. Well, there are a couple of vulnerabilities with retuning JSON arrays, but we are not considering these here. – dennis Aug 26 '14 at 20:14
  • Ah, did not know that you can't do wildcard CORS with credentials in a browser, thanks for that. Anyway, still doesn't matter, as long as evil.com has your client_id and access token, it can do a back-end request, no CORS required. – Boy Baukema Aug 27 '14 at 07:21
  • 1
    (as long as evil.com has your client_id and access token) - evil.com does not have my access token, it must steal it first :) Backend request will not work either - evil.com does not have my cookies in its backend so it only can make requests with credentials from the browser. So I am still not seeing how it is possible to steal the access token... – dennis Aug 27 '14 at 13:33