alignment with OAuth 2 flows for 1P authorization servers

[dickhardt]

It seems like it would be beneficial for the OAuth 2 pattern of separate access and refresh flows to fit into the DBSC pattern. In this separation, the policy of what the user is allowed to do is only evaluated on refresh, and the result is encoded in the access token enabling the resources to only verify the access token grants access to the resource.

In the cookie refresh flow in DBSC, the server would not only determine if the session is still authenticated, but if access is still authorized. IE, the server would evaluate policy when refresh is called. This functionality in OAuth 2 is done at the token endpoint. For adoption of DBSC into OAuth 2 architectures, aligning the protocol with how the OAuth 2 endpoint would simplify adoption.

IE having the DBSC only being additional headers would prevent it from conflicting with OAuth 2, or having the JSON response be additive to the existing OAuth 2 token endpoint response.

This could lead to using device bound cookies for refreshing access tokens rather than a bearer or DPoP refresh flow, substantially improving 1P OAuth flows.

Happy to discuss in more detail if interested.

[wparad]

Yes please. It seems almost a requirement that DBSC either uses OAuth2 existing functionality exactly as it is has been detailed in the RFCs or created in such a way to interoperate with an existing flow.

I'm not sure it matters which path is taken. I.e.:

• DBSC should explicitly be the DPoP implementation
• Or DBSC conforms to enable OAuth2 refresh_token grant from the device

But realistically it does feel like one of these should be true if we are going to get adoption of this. For instance, if we don't pick either of those, then there is no way that it can interoperate with OAuth2, which basically means that no OAuth2 server can support this. Which at this point seems like "every system which would benefit from DBSC won't implement it".

[mattjm]

I mentioned #12 in another thread but I wonder if that discussion applies here as well, since one proposal there is overloading the /token endpoint.

I'm not quite following how the oauth2 pattern of separate refresh and access tokens applies here. What would that look like in practice for this context?

[dickhardt]

My off the cuff thinking on how DBSC would align with OAuth 2 refresh is to for the browser to manage the access token rather than the SPA. A new grant type would be defined that would be passed to the token endpoint, and the AS would then set the access token in a HTTP header for the browser to acquire, and provide paths for when the browser would pass the access token. The browser would then pass the access token ideally in the Authorization header for any calls to those paths, or alternatively pass the access token as a cookie.

The browser could optionally know when the access token would expire and perform the refresh to the token endpoint, or this could be left to application logic as it is today.

Ideally the Browser would also manage a key pair that would be used in the initial call to the token endpoint to send a DPoP header and then send a DPoP header on API calls.

This allows SPA developers to not have to manage access tokens or DPoP and minimizes the risk of exfiltration of access tokens and DPoP keys.