3 ms·

Yeah but that also means your users will have to re-login every 24h. Other implementations (i.e. Keycloak) issue refresh tokens on the implicit flow.

taeric 2y ago
Is it ok practice to store the refresh token in local storage, then?
- littlecranky67 2y ago
  I think that is the only way to do it if you use any openID connect implenmentations - which is often my criticism about it. Modern browsers can have cookies using SameSite=strict and HttpOnly cookies, which I would consider better than storing refresh tokens in localStorage or even expose them at all to javascript. But OpenID Connect predates those browser features, so everyone seems okay with it.
  - taeric 2y ago
    My scenario still makes it impossible to use those, sadly. Specifically, I do not have any servers involved. Completely static javascript served up through s3, basically. If my threat model gets to where I care about this, I suppose my only real options is doing the redirect to a compute backed address. For now, glad I don't have to worry about it. :D
    - littlecranky67 2y ago
      I had the same setup and was dissapointed with OAuth/OpenID Connect same as you, as there is NO way to make that work with modern flows. Your only option is to use the implicit flow and store refresh/access token in localStorage. The "modern" code flow involves a piece of backend code that performs the exchange of the code for tokens - and you are actually not supposed to make those token available to the (insecure) browser.
      - taeric 2y ago
        Being fair, the code flow can be done on the client. And it does protect from most of the URL sniffing attacks that are there for the implicit flow. It just feels weird to still be doing all of that from the client.
        littlecranky67 2y ago
        I'd be genuinely interested how you can do the code flow on the client (browser). So far, all OAuth providers I tested will not let you do that due to CORS issues.

taeric 2y ago

Is it ok practice to store the refresh token in local storage, then?

littlecranky67 2y ago
I think that is the only way to do it if you use any openID connect implenmentations - which is often my criticism about it. Modern browsers can have cookies using SameSite=strict and HttpOnly cookies, which I would consider better than storing refresh tokens in localStorage or even expose them at all to javascript. But OpenID Connect predates those browser features, so everyone seems okay with it.
- taeric 2y ago
  My scenario still makes it impossible to use those, sadly. Specifically, I do not have any servers involved. Completely static javascript served up through s3, basically. If my threat model gets to where I care about this, I suppose my only real options is doing the redirect to a compute backed address. For now, glad I don't have to worry about it. :D
  - littlecranky67 2y ago
    I had the same setup and was dissapointed with OAuth/OpenID Connect same as you, as there is NO way to make that work with modern flows. Your only option is to use the implicit flow and store refresh/access token in localStorage. The "modern" code flow involves a piece of backend code that performs the exchange of the code for tokens - and you are actually not supposed to make those token available to the (insecure) browser.
    - taeric 2y ago
      Being fair, the code flow can be done on the client. And it does protect from most of the URL sniffing attacks that are there for the implicit flow. It just feels weird to still be doing all of that from the client.
      - littlecranky67 2y ago
        I'd be genuinely interested how you can do the code flow on the client (browser). So far, all OAuth providers I tested will not let you do that due to CORS issues.