Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[David Waite <[e-mail]>]

> On Nov 21, 2018, at 12:08 AM, Hans Zandbelt <[e-mail]> wrote:
> 
> I think of this as somewhat similar to:
> a)  a grant type where a cookie grant is exchanged at an "RP token endpoint" for an associated access and refresh token; the protocol between SPA and the API to do so would benefit from standardization e.g. into SDKs and server side frameworks
> b) an "RP token introspection endpoint" where the cookie is introspected at the RP and associated tokens are returned
> 
> if anyone comes up with a better name for this model and endpoint (and probably less overloading of AS endpoint names...) and/or is willing to help writing this down, please come forward and we'll pick it up on a new thread/doc 

Hand waving follows :-)

This sounds like the RP environment as two pieces, a javascript application and back-end infrastructure. The RP infrastructure maintains local tokens which it derives from remote tokens issued by a single upstream AS/IdP, which it interacts with as a confidential client.

This RP infrastructure separately manages authentication/authorization for a javascript application. In this use case, this infrastructure allows the javascript application to get the access token issued by the upstream AS, so that the javascript application may then act as the client to interact with protected resources associated with that AS. (For protected resources within the RP environment, a separate local token is used for authorization; possibly a non-OAuth token such as the cookie)

The first requirement of access token exposure sounds like a fit for token exchange, with the RP exposing its own authorization service token endpoint for this purpose, and the javascript acting as a public client to the RP and not to the upstream OAuth AS. The “cookie token” would have a specific token type for this use case. Multiple exchanges would potentially return the same upstream access token, or could silently use the refresh token if needed to acquire and return a fresh access token.

In this scenario I would not expose the refresh token, as the javascript application should not have a direct relationship with the upstream AS, nor should it have credentials to perform the refresh.  Likewise, the id_token was addressed to the RP infrastructure and not the javascript application - I would expect authentication interactions to be between the RP infrastructure and the javascript application, indirectly based on the RP infrastructure’s relationship upstream service.

Once the javascript app has the access token, it should be able to use it to interact with a user info endpoint. This might be a RP user info endpoint, or the upstream user info endpoint, depending on RP requirements.

FWIW, if there are multiple upstream AS’s, I would expect the local RP environment to be a ‘full fledged’ AS issuing its own local access tokens, and to provide its own local protected resources which then may dispatch to the protected resources of the various upstream AS’s as needed. Everything above could be reused in this scenario, although you might just decide to have the local protected resources accept the cookie directly in addition to the local RP environment access tokens.

-DW