Yes. Calling delete on those `AccessToken` instances would cascade to related `RefreshToken` instances, but the reverse is not true. If we were to add an `on_delete` argument to the `RefreshToken.access_token` model field, this could be prevented and/or dealt with in a predictable way.

The problem with refresh tokens not having an associated access token though is that when executing a token refresh later, the access token scope would not be known. So, basically, the one-to-one relationship between the two makes should be strictly enforced.

One way of dealing with this is to enforce a lifespan on refresh tokens similar to access tokens. Meaning, if refresh tokens have either been flagged by `expired=True` or if they are at least N hours/days/weeks (timedelta) old, _then_ it's safe to delete them. Of course, by adding an `expires` field on refresh tokens, we really wouldn't need the `expired` flag, but it might be good to keep around for backwards compatibility.

And just for clarity, the RFC for OAuth v2 leaves this up to the authorization server. From [Section 1.5](http://tools.ietf.org/html/rfc6749#section-1.5):

>  The client authentication requirements are based on the client type
>  and on the authorization server policies.

So, perhaps this can be described in settings? Something like `OAUTH_REFRESH_EXPIRE_DELTA`?