Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Foreword

All the content here is to the best of my understanding. However, since this relates to security, don't use this as a definitive reference.

...

While this works great for backend services able to keep refresh tokens and client secrets secure and private, we are using a web app where the source code is intrinsically publicly available. This would include any client secrets. Additionally, a malicious XSS attack could just grab the refresh token instead of the access token, and use that to keep obtaining new access tokens. 

Some systems are available such as refresh token rotation, which we may implement in future.

In summary, refresh tokens are wonderful if used properly, but using them properly is extremely difficult in public web apps. We instead have to take different approach, once again letting someone else do the work for us.

Using Okta to manage sessions

We don’t want to deal with sessions for a bunch of reasons, but we can, and should, let someone else do it for us. Our auth flow works like this:

...

 

Rotating refresh tokens

To mitigate the issues surrounding stolen refresh tokens, we make use of single-use "rotating" refresh tokens. An excellent overview of these tokens can be found at https://developer.okta.com/

...

docs/

...

guides/

...

This isn’t “seamless”, since the user gets a couple of quick redirects every hour or so, but it provides short-lived access tokens with persistent login without refresh tokens or us managing sessionsrefresh-tokens/refresh-token-rotation/

Essentially, any refresh token is single-use. The refresh token can be exchanged for a 15-minute access token, and another new refresh token. As soon as a refresh token has been used once, it is invalidated and cannot be used again. Likewise, once a refresh token has been unused for some time (1 hour for us), it is invalidated and the application requires re-authentication.


Using Okta to manage sessions

When a user is required to re-authenticate, their Okta session may be used to speed up the process. If, when signing in, the user checks the "Remember me" option, their session will be stored and managed by Okta. This way, even if their refresh token expires, they can be logged in without direct user-interaction. We can then configure Okta to log out inactive users after a timeout, requiring re-entering a password.

How is this different from the “old” web apps?

...