In Ory OAuth2 and OpenID Connect (OIDC), refresh tokens are designed to be rotated and are single-use by default. When a client uses a refresh token to obtain a new access token, a new refresh token is issued and the previous one is invalidated. This process does not require the user to re-authenticate; the client can continue to use the new refresh token to obtain new access tokens as long as the refresh token remains valid and unexpired. The user only needs to re-authenticate if the refresh token expires or is revoked, or if the flow is explicitly configured to require re-authentication for certain actions or scopes. You can also configure the lifespan (TTL) of refresh tokens, but extending the refresh token itself (i.e., increasing its expiration time) is not a standard operation—refresh tokens are rotated, not extended in place. The refresh token's validity is managed by issuing a new one upon each refresh request, not by extending the existing token's expiration. This mechanism allows clients to maintain long-lived sessions without user interaction, as long as the refresh token is valid and securely stored [Refresh token rotation and security protections](https://www.ory.sh/docs/oauth2-oidc/refresh-token-grant#refresh-token-rotation-and-security-protections) [Change refresh token lifespan](https://www.ory.sh/docs/oauth2-oidc/refresh-token-grant#change-refresh-token-lifespan). If you want to change the default lifespan for newly issued refresh tokens, you can do so via configuration, but this does not affect already issued tokens:

ory patch oauth2-config --project <project-id> --workspace <workspace-id> \   --replace "/ttl/refresh_token=\"900h\"" \   --format yaml

[Change refresh token lifespan](https://www.ory.sh/docs/oauth2-oidc/refresh-token-grant#change-refresh-token-lifespan) In summary: - You do not need user re-authentication to use a refresh token and obtain new tokens. - You cannot "extend" an existing refresh token's expiration; you can only configure the lifespan for new tokens. - The refresh token flow is designed for seamless, non-interactive token renewal as long as the refresh token is valid.

Yes, when you use a refresh token to acquire a new access token in Ory, you also receive a new refresh token. The previous refresh token becomes invalid after use—this is known as refresh token rotation. This mechanism enhances security by ensuring that refresh tokens are single-use only. Every time a client uses a refresh token to request new tokens, a new refresh token is issued and the old one is invalidated [Refresh token rotation and security protections](https://www.ory.sh/docs/oauth2-oidc/refresh-token-grant#refresh-token-rotation-and-security-protections). This behavior is the default in Ory OAuth2 and OIDC implementations.

The knowledge sources do not explicitly state whether a refresh token is invalidated automatically upon a password change. However, they do describe mechanisms for session and token invalidation in related scenarios: - In Ory Kratos, you can configure the system to revoke all active sessions when a user recovers their account (such as after a password reset) by using the

revoke_active_sessions

hook. This forces re-authentication for all sessions, but it is not explicitly stated whether this also revokes OAuth2 refresh tokens [Invalidate other sessions](https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset#invalidate-other-sessions). - For OAuth2, refresh tokens are invalidated if abuse is detected or if they are used more than once (unless a grace period is configured), but there is no direct mention of password change as a trigger for refresh token invalidation. In summary, based on the available documentation, it is not clearly specified that refresh tokens are invalidated on password change by default. You may need to implement session or token revocation logic explicitly if this behavior is required.