Closed dteleguin closed 1 year ago
Can device_session effectively provide this capability? Should we require DPoP for all step-up cases (the public key becomes the indicator).
If we use device_session, what are the security considerations?
Decisions:
We will use device_session and update security considerations to discuss how to sender constrain the device_session parameter.
Can device_session effectively provide this capability?
I think it can, but only if we're stepping up a (previously established) native session. If the session was not native (i.e. classic OAuth2.0), we will need a way to obtain a device_session first.
We are trying to compensate for the lack of session management (no cookies). We want something that behaves like a browser cookie.
Enumerating use cases:
Can this be solved by a Refresh token or DPoP instead?
Decision: Rename device_session to auth_session
Add guidance to store it even after the auth code expired
Extend the token endpoint response to include the auth_session as well.
Security considerations on protecting the auth_session parameter.
The auth_session
parameter is now defined in the successful token response, so an AS can return a value to the device even if the first access token was obtained through the redirect flow.
For step-up and similar cases, we'll need a way to communicate the existing session information to the authorization challenge endpoint.
We already have
id_token_hint
, but the problem is that ID tokens would generally contain no session identifiers (in some cases they would, e.g. OIDC Front Channel Logout requires the presence of thesid
claim in the ID token; but again, that's not the general case). Refresh token seems a better candidate as it has stronger relation to the session.