Silent refresh depends on session being held by other means

[srenatus]

When I use the sample app, point it at my OIDC provider, and select "Test Silent Refresh", I see the following request in Network tab of dev tools:

http://localhost:4200/dex/auth?response_type=id_token token&client_id=spa-demo&state=j24zpXv4aC1AHYdPUp2X4aA972SHamXrW0q5SHWH&redirect_uri=http://localhost:4200/silent-refresh.html&scope=openid profile email&nonce=j24zpXv4aC1AHYdPUp2X4aA972SHamXrW0q5SHWH&prompt=none

So, to have this work, we depend on the IdP to have the means to identify the user's request, for example by using cookies.

An alternative way, according to the oidc core 1.0 specs, is to provide an id_token_hint, which is some old token the client might have:

id_token_hint
OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.

[manfredsteyer]

Thx. The next version (will land in a few days) will contain a config flag useIdTokenHintForSilentRefresh. It is set to false by default to prevent breaking changes.

[srenatus]

Great. I can't find this in the code yet, though. 😉 Am I missing something?