What are the dangers of keeping the Oauth2 token on the frontend?

Question

I believe I am paranoid, but I could not find any situation similar to mine (if you know pass me the link, I am grateful) so I wanted to ask this question to get a definitive answer.

Before the question some information about our infrastructure:

My company is the one who keeps the Authorization Server, the Resource Servers and the Clients.
There may be Clients of third parties, but will be restricted to some Resources Servers.

A little bit of history:

We recently decided to implement SSO (Single Sing On) with Oauth2 in my company’s systems.

I already have one Authorization Server made with Spring Boot and configured some of our old systems that still used Springframework 3.x + JSF as Client, and so far everything is working properly.

We are currently in the process of creating a new frontend in Reactjs to eventually depress the JSF (so I had to do the frontend separate from the backend).

My strategy was to create an api as a Resource Server along with the Client (JSF) so that the two of them share the logic of business (so that developers who have not yet become familiar with React can continue to maintain the JSF screens and meanwhile we migrate to React little by little).

The Problem:

To log in, I redirect the user to a published url of Resource Server which redirects the user back to the Authorization Server with the credentials of Client (which are hidden within the Resource server) and after the user logs in, the whole process of getting the sponse code and trade for access token is done in the backend, at the end the user is redirected back to the frontend in React with the access token inside a cookie (I opted for a cookie instead of sending in the url only to hide from the user).

My concern is that I have to keep the access token in the Cookie with httpOnly=false so that I can identify in the frontend that the user is logged in as well as to send it in the header Authorization requests to the Resource server.

One of the recommendations I found most for Reactjs applications logged in to Oauth2 was to create a backend to control the sessions and save the access token in the backend, but all these cases are when the Client uses a social login such as Google, Facebook or Twitter and not its own, IE, it has to have a backend to maintain the credentials of the Client. Besides it seems to me redundant to have create a backend just to hide oauth token with what will be essentially another token to identify the session.

TL;DR:

Is there any danger in keeping only the Oauth2 Access Token inside a cookie without the flag httpOnly?

And if so, how can I avoid these dangers?

In my view it is only necessary to protect the client’s credentials, after all, if the user has any malicious software on his computer or is accessing our system from an iframe on a forged website that can steal the token stored in the cookie or localStorage, which prevents this same software/site from stealing the password that the user typed in the browser?

Answer 1

It’s interesting you raise these two scenarios:

1. Cookie storage, vulnerable to CSRF, and also has a giant list of options to prevent (however, using cookies is discouraged by the specification)
2. The storage via local Storage / Secure Storage, which is vulnerable to XSS, and which also has a giant list of options to prevent

There are two important details in its implementation:

• Your choice to leave httpOnly Disabled automatically leaves you vulnerable to XSS attacks
• Perhaps the essence of Bearer Token is not being taken into account fully

Think that the Bearer Token (or carrier token) is the user authorization, with this token your application understands that the user carrier is in fact who is said to be.

But why the token is reliable?

For you to deliver the token to someone, it proved to be who it says to the authorization server through your credentials (clientId and secret).

In the case of a JWT, you signed it with your information, to be able to verify that it was yourself that generated that token, and when the user sends you your application to be able to verify that the token was not changed.

It is a problem to leave the token in open place susceptible to attacks?

Yes! In fact, it’s a big problem, in case any attacker gets his client’s token, he will be able to pass him without any problem.

Even the option to leave the token in a cookie is strongly discouraged if appropriate preventive measures are not taken by RFC6750 - Bearer Token Usage:

Cookies are typically transmitted in the clear.  Thus, any
information contained in them is at risk of disclosure.  Therefore,
bearer tokens MUST NOT be stored in cookies that can be sent in the
clear.  See "HTTP State Management Mechanism" [RFC6265] for security
considerations about cookies.   

...

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.

But now what I do I think everything is unsafe I will disconnect from the internet

To our delight, the people who created the Oauth2 framework gave us a lot of material related to security.

You can read the safety considerations on RFC6749 - Oauth2 Framework, and this subject is so extensive that it was also created to RFC6819 - Oauth2 Threat Model which mentions various forms of attack against the model, including token theft (impersonation Attacks).

Some of the token-related framework recommendations mentioned in RFC6750 sane:

1. Store tokens in safe place
2. Validate the TLS certificate chain of those involved
3. Always use TLS / HTTPS
4. Not storing Bearer Tokens in cookies without proper care
5. Provide expiry date for tokens
6. Provide actuation scope for tokens
7. Do not pass tokens in the application URL

In short

Implementing an authorization framework like Oauth2 is a bit more complex than just generating and receiving tokens as you can see.

As I have shown in the specifications, both the cookie and the local Torage have safety considerations, and you should weigh what the prevention cost of each solution is. There are ways to prevent against possible attacks for both cases (a good article comparing the two forms is this one).

I recommend you read the Rfcs I mentioned in the response, they have great material, as well as examples of attacks and preventions.