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 Hans. On Tue, Nov 20, 2018 at 11:00 PM George Fletcher <[email protected]> wrote: > +1 > > This model is useful and should be documented in its own right. Once > documented it could possibly be referenced in the BCP. > > On 11/9/18 1:44 PM, David Waite wrote: > > Hi Hans, I hope it is acceptable to reply to your message on-list. > > Others could correct me if I am wrong, but I believe the purpose of this > document is to recommend uses of other OAuth/OIDC specifications, not to > include its own technologies. > > In terms of being another spec to be referenced, I think it would be > useful but I wonder hypothetically how to best write that specification. > This method seems to be relying on standards-defined tokens and converting > them to an application server session, which isn’t defined by behavior > other than HTTP cookies. The session info hook then lets you use those > proprietary session tokens to retrieve the access/id token. > > As such, it is closer to an architecture for implementing a client - as a > confidential client backend with an associated SPA frontend that needs to > make OAuth-protected calls. It is not describing the communication between > existing OAuth roles, such as between the client and AS. > > There’s obvious value here, and it's one of several architectures for > browser-based apps using a confidential client rather than a public one > (another example being a reverse proxy which maps remote OAuth endpoints > into local, session-token-protected ones). I personally am just not sure > how you would define the communication between back-end and front-end > portions of the client in these architectures as a standard within OAuth. > > -DW > > On Nov 6, 2018, at 3:03 AM, Hans Zandbelt <[email protected]> > wrote: > > Hi Aaron, DW, > > About draft-parecki-oauth-browser-based-apps: > would you consider including a recommendation about and the > standardization of a "session info" endpoint (I'm open for better naming > ;-)) as described in: > > https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/ > > this approach is not just something that I cooked up; it is based on real > world requests & deployments at Netflix and OAth. > > Let me know what you think, > > Hans. > > On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig < > [email protected]> wrote: > >> Hi all, >> >> Today we were not able to talk about >> draft-parecki-oauth-browser-based-apps-00, which describes "OAuth 2.0 for >> Browser-Based Apps". >> >> Aaron put a few slides together, which can be found here: >> >> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf >> >> Your review of this new draft is highly appreciated. >> >> Ciao >> Hannes >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > [email protected] > ZmartZone IAM - www.zmartzone.eu > > > > > _______________________________________________ > OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth > > > -- [email protected] ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
