How does an OpenID Connect session refresh work, and why does the user not have to log in again?

The RP sends its still-valid refresh token, authenticated with its client credentials, directly to the token endpoint (grant_type=refresh_token) over the back channel; the OP checks the token and the client and returns a new access token and a new refresh token, with no browser redirect and no user interaction.

0. Verify the session: the RP wants to extend the user's session (for example the user clicks "continue" on an e-learning platform after the access token expired) and still holds a valid refresh token.

1. a) Token request (HTTP POST, back channel, TLS mandatory): the RP sends grant_type=refresh_token, the refresh token, the scope, and authenticates itself:

   POST /token
   client_id=s6BhdRkqt3&client_secret=some_secret12345
   &grant_type=refresh_token&refresh_token=8xLOxBtZp8&scope=openid%20profile
   

   b) Validation and response: the OP checks that the refresh token is valid, that it was issued to this client, and that the client authenticated successfully. It returns a new access_token (TlBN45jURg), token_type: Bearer, a new refresh_token (9yNOxJtZa5) and expires_in: 3600.

The user's browser only sees the RP's page reload; it never visits the OP. That is the purpose of the refresh token: long-lived access without repeated authentication, while the access token itself stays short-lived.

Go deeper:

• OpenID Connect Core 1.0: Using Refresh Tokens — the refresh request and response, including the optional new ID token.
• RFC 6749, Section 6: Refreshing an Access Token — the underlying OAuth mechanism.