Does it make sense to use refresh tokens in combination with FIDO2 authentication?

Question

An OpenID Connect authentication process for native apps can optionally return a long-lived refresh token that can be securely stored on the device. This allows users to subsequently use a pass-code or biometric to unlock the refresh token that's stored on the device and then authenticate using a refresh token exchange. Essentially, refresh tokens facilitate a better CX by allowing users to authenticate with a pass-code or biometric instead of a username + password/OTP.

With FIDO2 authentication, users will authenticate with platform authenticator, which could be something like Touch ID, Face ID, or Windows Hello depending on the device/platform.

In terms of the CX, you could potentially make the argument that using a platform authenticator is the equivalent of using a pass-code or biometric to unlock a refresh token. With this in mind does it make sense to use refresh tokens in combination with FIDO2 authentication?

Reasons for:

1. Access tokens are typically short-lived (e.g. 15 mins). If the user session goes for longer than the access token expiry, then the app could potentially do a refresh token exchange using a refresh token that's already been unlocked. That said, there seems to be other ways to do this without using the refresh token e.g. silent auth with PKCE flow and the prompt=none parameter on the authentication request e.g. see here for how this is done with Auth0.
2. You could potentially make the argument that using a pass-code or biometric to unlock a refresh token is a slightly better CX than FIDO2 auth, as the user doesn't need to leave the native app, whereas with FIDO2 auth (following BCP for authentication in native apps), the app would still need to open an external browser (or in-app browser tab) to the authorization server.
3. Some users might want to use an external authenticator, and not all users might be using a device with a built-in platform authenticator - basically, we probably shouldn't make any assumptions.

Reasons against:

1. Not having to deal with refresh tokens removes some security vectors
2. Consistent UX for auth
3. Consistent authentication CX between native apps and web apps (where we typically don't use refresh tokens).
4. Additional work to set up refresh tokens, as opposed to just going to the authorization server every time.

IMHO it does still make sense to use refresh tokens in combination with FIDO2 authentication, but keen to hear thoughts...

Answer 1

I'll start with a TLDR. Yes, it makes sense to use Refresh Tokens in combination with FIDO2 authentication. Refresh tokens are used to re-issue access tokens without user interactions for a better user experience and easier handling of authorizations in resource servers, as per the OAUTH2 spec. while FIDO credentials are used to authenticate a user, which always includes user interaction.

The answer

To start, my answer will be based on refresh token from OAuth2, which is the underlying technology used with OpenID Connect (OIDC). As such it makes more sense to talk about refresh tokens from OAuth2 than from OIDC. The basic idea with a refresh token is to be able to grant new access tokens without requiring user interaction. User interaction here could be things like inputting username and password or using a FIDO2 credential. The key benefits with the refresh token instead of just extending the lifetime of the access token is that you mostly would use the access token towards a resource server and not the actual authorization server. So when your access token expires your system can request a new token from the authorization server which you can then use towards the resource server. This way the resource server never needs to know about the refresh token or how they work. There are of course variations on this but this is the general gist of the OAuth2 specification.

So refresh tokens add a strong user experience benefit to any system. And as always with bad user experience when it comes to security, it tends to lead to people adapting and finding ways around the security. However, refresh tokens being opaque strings means if they are stolen they are easy to abuse. OAuth2 does have techniques to combat this like DPoP. But from a security perspective, having to redo an authentication based on asymmetric cryptography is more safe than using a refresh token. With that mindset though, it also more safe to not use access tokens at all but require authentication on every single request, which would result in a terrible user experience.

If we move more into your example, where you protect the refresh token through some sort of user interaction. User interaction here can be anything you mention, Touch ID, Face ID, Pin code. Adding this to make the refresh token more safe is reasonable to do but not very far the requirement of doing just an actual re-authentication, which is what you would get from using a FIDO credential to get a new token. And if the FIDO credential is living on the same device as you would have the refresh token, using the FIDO2 credential would be safer than using a refresh token. The problem here though comes from the fact that FIDO is supported on external devices. So you might have used a passkey stored on your mobile phone or you might have an external hardware based authenticator storing it. If you were then to to require a FIDO credential to refresh the token, you might be forcing the user into using a 2nd device each time the token needs to be refreshed. But with the refresh token you can guarantee that the refresh token lives on the same device as the access token.

With that in mind, using the refresh token, even if you add the extra user interaction to protect it, results in the expected user experience you want. FIDO2 can here result in a very negative user experience with having to authenticate on a secondary device, which would most likely lead to the user finding a way to bypass that security feature. And that alone makes it make more sense to use a refresh token.