Using OAuth2 in HTML5 Web App

Solution 1:

It looks like you're using the Resource Owner Password Credentials OAuth 2.0 flow e.g. submitting username/pass to get back both an access token and refresh token.

• The access token CAN be exposed in javascript, the risks of the access token being exposed somehow are mitigated by its short lifetime.
• The refresh token SHOULD NOT be exposed to client-side javascript. It's used to get more access tokens (as you're doing above) but if an attacker was able to get the refresh token they'd be able to get more access tokens at will until such time as the OAuth server revoked the authorization of the client for which the refresh token was issued.

With that background in mind, let me address your questions:

1. Either a cookie or localstorage will give you local persistence across page refreshes. Storing the access token in local storage gives you a little more protection against CSRF attacks as it will not be automatically sent to the server like a cookie will. Your client-side javascript will need to pull it out of localstorage and transmit it on each request. I'm working on an OAuth 2 app and because it's a single page approach I do neither; instead I just keep it in memory.
2. I agree... if you're storing in a cookie it's just for the persistence not for expiration, the server is going to respond with an error when the token expires. The only reason I can think you might create a cookie with an expiration is so that you can detect whether it has expired WITHOUT first making a request and waiting for an error response. Of course you could do the same thing with local storage by saving that known expiration time.
3. This is the crux of the whole question I believe... "How do I get a refresh token, without A, storing it with the original access_token to use later, and B) also storing a client_id". Unfortunately you really can't... As noted in that introductory comment, having the refresh token client side negates the security provided by the access token's limited lifespan. What I'm doing in my app (where I'm not using any persistent server-side session state) is the following:

• The user submits username and password to the server
• The server then forwards the username and password to the OAuth endpoint, in your example above http://domain.com/api/oauth/token, and receives both the access token and refresh token.
• The server encrypts the refresh token and sets it in a cookie (should be HTTP Only)
• The server responds with the access token ONLY in clear text (in a JSON response) AND the encrypted HTTP only cookie
• client-side javascript can now read and use the access token (store in local storage or whatever
• When the access token expires, the client submits a request to the server (not the OAuth server but the server hosting the app) for a new token
• The server, receives the encrypted HTTP only cookie it created, decrypts it to get the refresh token, requests a new access token and finally returns the new access token in the response.

Admittedly, this does violate the "JS-Only" constraint you were looking for. However, a) again you really should NOT have a refresh token in javascript and b) it requires pretty minimal server-side logic at login/logout and no persistent server-side storage.

Note on CSRF: As noted in the comments, this solution doesn't address Cross-site Request Forgery; see the OWASP CSRF Prevention Cheat Sheet for further ideas on addressing these forms of attacks.

Another alternative is simply to not request the refresh token at all (not sure if that's an option with the OAuth 2 implementation you're dealing with; the refresh token is optional per the spec) and continually re-authenticate when it expires.

Hope that helps!

Solution 2:

The only way to be fully secure is to not store the access tokens client side. Anyone with (physical)access to your browser could obtain your token.

1) Your assessment of neither being a great solution is accurate.

2) Using expiration times would be your best if you are limited to only client side development. It wouldn't require your users to re-authenticate with Oauth as frequently, and guarantee that the token wouldn't live forever. Still not the most secure.

3) Getting a new token would require performing the Oauth workflow to obtain a fresh token. The client_id is tied to a specific domain for Oauth to function.

The most secure method for retaining Oauth tokens would be a server side implementation.

Solution 3:

For pure client side only approach, if you have a chance, try to use "Implicit Flow" rather then "Resource owner flow". You do not receive refresh token as a part of the response.

1. When user access page JavaScript checks for access_token in localStorage and checks it expires_in
2. If missing or expired then application opens new tab and redirects user to the login page, after successful login user is redirected back with access token which is handled client side only and preserved in local storage with redirect page
3. The main page might have polling mechanism on the access token in local storage and as soon the user logged in (redirect page saves token to storage) page process normally.

In the above approach the access token should be long living (e.g. 1 year). If there is a concern with long living token you can use following trick.

1. When user access page JavaScript checks for access_token in localStorage and checks it expires_in
2. If missing or expired then application opens hidden iframe and tries to login user. Usually auth website has a user cookie and stores grant to the client website, therefore login happens automatically and script inside iframe will populate token into storage
3. The client's main page sets polling mechanism on access_token and timeout. If during this short period the access_token is not populated into storage, it means that we need to open new tab and set normal Implicit flow in motion