But again, what's the difference between that and just having a moderately-long access token if you'll still be handing out access tokens for the lifetime of the refresh token?
1. You can check for user changes when the refresh token is used and a new access token is requested (user deleted, permissions changed, access revoked)
2. Refreshes can go to a different endpoint, whereas access tokens could be used with services that don’t even have access to user auth services.
Edit: There is something to be said for ditching the refresh token and just re-authenticating when the access token expires. The benefit is that you don’t need to store the username/password in the client code to re-auth, and you might avoid some relatively expensive password checking on the server, but that is probably pretty minor.
1. You can check for user changes when the refresh token is used and a new access token is requested (user deleted, permissions changed, access revoked)
2. Refreshes can go to a different endpoint, whereas access tokens could be used with services that don’t even have access to user auth services.
Edit: There is something to be said for ditching the refresh token and just re-authenticating when the access token expires. The benefit is that you don’t need to store the username/password in the client code to re-auth, and you might avoid some relatively expensive password checking on the server, but that is probably pretty minor.