I agree with you. I think it would also be good to elaborate on Refresh Token purpose in your response. As you know, the Refresh Token is used to separate the responsibility of access revocation from the 'resource provider' and put it back on to the authorisation server / identity provider, where it belongs. If somebody loses their mobile device and wants to revoke access, this can be done by notifying the identity/auth provider, who revokes the refresh token. The backend API providing the resources cannot easily do that without for example either maintaining its own access logic (overlap of responsibility with auth provider) or revoking signing keys (invalidates all other access tokens too). I think this knowledge is implicit in what you write but would be best made explicit.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you. I think it would also be good to elaborate on Refresh Token purpose in your response. As you know, the Refresh Token is used to separate the responsibility of access revocation from the 'resource provider' and put it back on to the authorisation server / identity provider, where it belongs. If somebody loses their mobile device and wants to revoke access, this can be done by notifying the identity/auth provider, who revokes the refresh token. The backend API providing the resources cannot easily do that without for example either maintaining its own access logic (overlap of responsibility with auth provider) or revoking signing keys (invalidates all other access tokens too). I think this knowledge is implicit in what you write but would be best made explicit.