> On Jul 23, 2019, at 12:47 PM, Brian Campbell
> <bcampbell=40pingidentity....@dmarc.ietf.org> wrote:
>
>
>
> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt <tors...@lodderstedt.net
> <mailto:tors...@lodderstedt.net>> wrote:
>
> 2) Regarding architectures: I think this BCP should focus on recommendations
> for securely implementing OAuth in the different potential architecture. I
> don’t think we should get into the business of recommending and assessing
> other solutions (e.g. section 6.1.). Just to give you an example: Section
> 6.1. states
>
> "OAuth and OpenID Connect provide very little benefit in this deployment
> scenario, so it is recommended to reconsider whether you need OAuth or OpenID
> Connect at all in this case.”
>
> Really? What experiences is this statement based on? In my experience,
> sharing the same domain == host name tells you nothing about the overall
> architecture of a certain deployment. There may be several reasons why OAuth
> could be good choice in such a scenario, e.g. security considerations (since
> your common domain is just a proxy server encapsulating a whole universe of
> systems) or even modularity as an architecture principle.
>
> I suggest to remove section c. and to rephrase the second paragraph of the
> abstract.
>
> I believe the experiences that the statement is based on are the predominant
> practice over the course of much of the history of the web of using a cookie
> to maintain an authenticated HTTP session in web applications. When the
> script of the browser-based application is served from a domain that can
> share cookies with the domain of the API, then cookies can still be used to
> authorize requests (even if those requests are API calls rather than full
> page HTTP request/response). And I do believe that's likely a better decision
> in a lot of such cases.
>
> That authenticated HTTP session may be establish from a username/password
> form submission, FIDO/WebAuthn, or whatever. Even as a result of an OpenID
> Connect flow. Or even SAML for that matter. But the the requests after that
> are authorized by the cookie.
>
> I think there's a tendency to assume because SPA style apps make API calls,
> they simply must use OAuth. Because API implies OAuth in the minds of many
> (which is a sign of its success). But OAuth isn't necessarily the only thing
> that can be used for API authorization. Cookies work too. I think/hope that's
> what Section 6.1. is getting at - providing some potential guidance that
> OAuth might not necessarily be the right choice in those cases where a common
> domain allows for a cookie. Perhaps the text in that section could be phased
> in a different or better way, but I think its useful to have some mention of
> in this document.
>
> Although taking out "and OpenID Connect" from the sentence quoted above might
> be more appropriate and alleviate some confusion.
>
Perhaps it should be turned into a stated document assumption (that the reader
has decided to use OAuth) rather than guidance later in the document (that
OAuth may not be the best fit)
There is AFAIK no set of security considerations or best practices we can point
to for “use some non-standardized system for acquiring and using cookies” or
even “here’s a standard for acquiring and using cookies”. Omitting some of the
moving pieces of OAuth might alleviate some security concerns, but also
resurrect some other security issues. The most immediate example that comes to
mind: using a HttpOnly cookie-as-token instead of an access token may mean that
you can’t have injected scripts exfiltrate the token, but applying the access
token was also a mitigation against browser CSRF for your APIs.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
