Refresh Token
Ayrıca şöyle anılır Refresh Token, refresh_token grant
An access token is deliberately short-lived, often minutes to an hour, so that a leaked one does limited damage. But re-running the full login flow every time an access token expires would mean asking the user to type in their password (or approve a redirect) constantly. A refresh token solves that: a longer-lived credential, issued alongside the access token, whose only job is to be exchanged, quietly, in the background, with no user interaction, for a fresh access token when the old one expires.
Because a refresh token lives longer and is more damaging if stolen, the
current best practice (not the original 2012 spec, which was looser) is
rotation: every time a refresh token is used, the server issues a
new refresh token and invalidates the old one. That turns a stolen
refresh token into a race, if the legitimate client uses it again after
a thief already has, the mismatch is detectable, because the token the
legitimate client is holding will already be invalid. It's the same
detect-a-replay logic that shows up elsewhere in this category (see DPoP's
jti replay guard) applied to a longer-lived credential instead of a
short-lived proof.
Where it comes from
The refresh token grant is defined inside OAuth 2.0's own core document, RFC 6749, not a separate RFC, sections 1.5 and 6 specifically. Its modern security posture, rotate on every use, prefer sender-constraining where possible, comes from later IETF guidance, the OAuth 2.0 Security Best Current Practice, developed over several years by the OAuth Working Group with Torsten Lodderstedt among its lead editors. Solidus wrote neither document.
Solidus today
auth.solidus.network issues refresh tokens on two paths: a plain opaque
refresh token for ordinary OAuth clients, and a DPoP-bound refresh token,
rotated on every use, and rejected if presented with a mismatched DPoP
key, for Solid-OIDC clients that requested offline_access (see DPoP).
Both are live, tested code, running on Solidus's public testnet with no
independent audit and no mainnet identity behind them yet.
See also
OAuth 2.0 is where this grant type is defined. DPoP is the sender-constraining mechanism applied to Solidus's rotated refresh tokens. Bearer Token is the plain access token a refresh token is exchanged for.
Nereden geliyor
Bunu başkası belirtti. Solidus bir araya getiriyor.
The refresh token is a core primitive of OAuth 2.0 itself, defined in RFC 6749 §1.5 and §6, edited by Dick Hardt and the IETF OAuth Working Group (October 2012), not a separate specification. Modern guidance on using it safely (rotate on every use, sender-constrain where possible) comes from the OAuth 2.0 Security Best Current Practice document, led by Torsten Lodderstedt among other editors. Solidus wrote neither; it implements both the base grant and the rotation guidance.
Bunu nasıl doğrularsınız
Bugün üretimde çalışıyor.
curl https://auth.solidus.network/.well-known/openid-configuration and check grant_types_supported for "refresh_token", live and present. POST to /token with grant_type=refresh_token and any garbage token returns a proper OAuth-shaped error rather than a crash, which you can verify with a single curl command and no account.