| Hiya, Sorry, I was wrong. According to the spec you definitely have to send the access token back in the response body[0]. However, a client can store them as cookies (or, as you mention, other places, such as a service worker[1]). This is useful if the client is a single page application (SPA), which may need to present the access token to other resource servers. RFC 6750 has something to say about how to store the bearer token [2]: > Don't store bearer tokens in cookies: Implementations MUST NOT store bearer tokens within cookies that can be sent in the clear (which is the default transmission mode for cookies). Implementations that do store bearer tokens in cookies MUST take precautions against cross-site request forgery. So, I apologize. The authorization server wouldn't send the access token as a cookie. Instead, there'd be a server side proxy which would request the token and then send it down as a secure cookie. Again, best practice would be to keep the access token on the server side proxy and just send a session id down to the client, but that sometimes doesn't work. Here is a diagram illustrating that path (with the 'store' entity acting as the proxy mentioned above)[3]. 0: https://tools.ietf.org/html/rfc6749#section-5.1 1: https://gitlab.com/jimdigriz/oauth2-worker 2: https://tools.ietf.org/html/rfc6750#page-13 3: https://fusionauth.io/learn/expert-advice/authentication/web... |
The way I see it with SPA and tokens in JS accessible space is that you're exposing your users to the possibility of token theft and user impersonation if someone is able pull off an XSS. This is not so different than using a session cookie that is not marked as 'httponly'. What's old is new again :)
I have also heard the argument that we shouldn't worry about token theft, because it's already too late if you're XSS'd, but I don't buy into that rhetoric(not saying XSS isn't incredibly bad).
Unfortunately I work in financial services, so we can't just skate by and assume that we're so uninteresting that an adversary with advanced capabilities wouldn't look to exploit our external or internal users somehow.
One another thing we're looking into is access tokens, like having the user re-authenticate or use a stronger factor(or multiple) to get the AS to grant them a very short lived, non-refreshable token to do their sensitive operation.
I'm going to check out the fusionauth blog for a bit more inspiration, if you're interested in continuing this discussion I would be interested in carrying it on.