There are a lot of misunderstandings about both cookies and refresh tokens and OAuth2.
First, it is not true that only confidential clients can use a refresh token. The OAuth2 protocol says that confidential clients must authenticate, but does not require confidential clients. Ergo, client authentication is optional on the refresh operation. See RFC 6749, Section 6, Refreshing An Access Token.
Second, you have to understand what the alternatives are:
- Forcing the user to enter his or her username and password every 5 minutes (whenever the access token expires)
- Long lived access tokens
- Authentication via HTTP Cookies
Everybody in the world, who doesn’t use refresh tokens, uses option #3. Authentication via cookies is functionally and security-wise 100% equivalent to storing a refresh token. Of course, with both tokens and cookies, there are options for where they are kept:
a. HTTP only,
b. secure (require TLS/SSL) and
c. session (in memory) vs. persistent (local, domain storage)
Of course, care must be taken to always use TLS/SSL to transmit either authentication cookies or tokens. Honestly, since we know most breaches occur from within the private corporate network, end-to-end TLS is a basic requirement anymore.
Finally, whether cookies or tokens are ever persisted, i.e. stored somewhere that survives closing the browser or even rebooting the device, depends on the trade-off you’re making between usability and security – for your application.