Given some comments above, it should be clarified that a refresh_token should never be exposed to the client side as it never expires nor changes. It can be stored encrypted in a JWT but it’s an information that should be exposed to trusted components only. It is extremely important especially if you’re using a third party service to emit access_tokens because you probably cannot revoke refresh_tokens.
In a OpenID Connect, which is based on OAuth 2.0, when an access_token is about to expire, the refresh_token is meant to be used by a backend to ask for a new access_token to the third party in charge of emitting tokens without asking for user interaction. It allows short living token and therefore you can make long authentication sessions that expires if no user interactions are made in a short interval.
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.
Given some comments above, it should be clarified that a refresh_token should never be exposed to the client side as it never expires nor changes. It can be stored encrypted in a JWT but it’s an information that should be exposed to trusted components only. It is extremely important especially if you’re using a third party service to emit access_tokens because you probably cannot revoke refresh_tokens.
In a OpenID Connect, which is based on OAuth 2.0, when an access_token is about to expire, the refresh_token is meant to be used by a backend to ask for a new access_token to the third party in charge of emitting tokens without asking for user interaction. It allows short living token and therefore you can make long authentication sessions that expires if no user interactions are made in a short interval.