Is it safe to save refresh_token locally?

[MetaZhi]

As angularjs is a client-based application, is it safe to save refresh_token locally?
In this project, the access_token and refresh_token are saved in the localStorage.

[NikolajDL]

If you save it in a httpOnly secure cookie it is. Otherwise it'll certainly be vulnerable to XSS attacks.

[raffaeu]

I want also to highlight the fact that, as soon as you start to work with a web application that authenticate against a security server using bearer tokens, you must work in SSL mode except if the application is executed inside a safe intranet. Despite the technology used, or the client side framework used, sharing communications using a bearer tokens require SSL, always.
You can read more on this blog post:
https://blog.apigee.com/detail/best_practices_for_oauth_2.0_vs._oauth_1.0_-_one_year_later

[MetaZhi]

In this project, the access_token and refresh_token are saved in the localStorage.

[NikolajDL]

Yes and it shouldn't. That exposes the refresh_token to XSS attacks.

[MetaZhi]

Then where should I save the tokens, I don't want my users to log in every time they view my site?
I have a RESTful back-end and OAuth2 support.

[NikolajDL]

You should save it in a httpOnly secure cookie. A cookie with the httpOnly flag, cannot be retrieved by javascript in browsers supporting the httpOnly flag (most modern) and the secure flag forces the cookie to be sent over SSL (again in browser supporting this flag).

You'll need a few changes both server and client-side to make this happen.

[mikkark]

We are implementing open id connect authentication + oauth2 authorization using IdentityServer. I asked them a question about how to be able to set a short access token lifetime but still be able to have a long user session in the browser without refresh tokens. In our project we have a pure angular app with no front server. I was directed to this example: https://github.com/IdentityServer/Thinktecture.IdentityServer3.Samples/tree/master/source/OAuthJS. It fetches a new access token based on a timer using a hidden frame. This way the access token can be short-lived (e.g. 5 minutes) but the user can have a longer browser session that is not linked to the lifetime of the token. We store the access token inside Javascript in order to be able to attach it to the API requests (API is located in a different URL from the authentication server).

[houssemzaier]

No problems if you use the proxy pattern. Save them into a crypted cookie and the proxy server will decrypt that token sended in a header, then the proxy will use the token to get resources from the api server. Finally it will send it back to the browser