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

[Hans Zandbelt <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <
> [e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> [e-mail]
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu