1

I am using OAuth auth code flow to generate access and refresh tokens and then I store them in two browser cookies that are not HttpOnly and send them back too the client.

The cookies need to be non HttpOnly because the client needs to know if an access token exists to know if it should talk with the authorization server and perform a refresh token flow to get new tokens.

How bad is this security wise ? What are the risks when the refresh / access token get stolen ? What are some ways to mitigate these risks ?

EDIT

Also, do you think PKCE can improve the security of refresh token in any way ? From what I understand, it can only improve the security of the auth code flow but after you obtain an access+refresh token it's not much different, you just don't need to use a secret when exchanging the refresh token for a new token pair. Thanks

Improve this question

2 Answers 2

Reset to default
2

The main element of risk is from XSS. If there is any XSS in your application, then it can be used to trivially steal your tokens.

As soon as such a token is stolen, the attacker can fully impersonate the user.

What isn't clear for me is why you need to have these cookies available outside HTML: can't you use another cookie for storing the public element of the cookie (maybe the whole payload or simply the expiration and whatever you need for your client to figure out if it needs to go to the auth portal) and keep the JWT tokens in HTTP-only cookies?

Improve this answer
1
  • I can use another cookie, but the client needs to make a call to /auth/token endpoint on the OAuth auth server with the refresh_token grant to perform the refresh token flow. So it needs to pass the refresh token to the auth server
    – Michael
    Commented Sep 13, 2018 at 12:38
0

I'd think long and hard about having a refresh token available client side with no protection. For a server-side app you'd typically store this inside a protected (i.e. encrypted a signed) HTTPS only cookie.

For a client side app like you describe in Open ID Connect you'd use the implicit flow (no refresh token) and to renew you'd use a silent prompt=none call to the authorize endpoint to get a new (short lived) access token. This scenario is still vulnerable to XSS since the access token will be stored in local or session storage or similar but no refresh token will be available.

Are you able to use OIDC with your IDP?

Improve this answer
2
  • Yes, I am able to use oidc,why ?
    – Michael
    Commented Sep 18, 2018 at 12:53
  • If you are able to then I'd follow the OIDC guidance and use the implicit flow and use a library like oidc-client-js to manage it.
    – mackie
    Commented Sep 18, 2018 at 14:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .