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].
Thank you for your replies and insight, it's really appreciated.
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.
> This is not so different than using a session cookie that is not marked as 'httponly'.
The difference is a session cookie is tied to one server, but an access token could be used with many different APIs or other services. That said, an access token may expire more quickly, so the devil is definitely in the details.
> 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.
That makes sense, for sure. You could definitely require MFA to get an access token and have it be short lived. At that point it gets to a question of UX and how much impact you want on your users, but I'm not familiar with all the requirements you have.
> 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.
Please do! Happy to respond here or if you want to check out the FusionAuth forum (which I monitor), you can find it on the the website under the resources tab.
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...