I think the implication is that the server-side would use something like OIDC
to the token server in order to establish the identity of the user. The
difference is that this would be driven from the server-side piece of the
application, as any other normal server-side client would. The result would
then simply be a cookie-based authentication session in the client, and any JS
code would leverage the http only, same-site cookie for Ajax calls.
-Brock
On 7/21/2019 10:22:38 PM, Leo Tohill <leotoh...@gmail.com> wrote:
The advice for the architectural pattern "JavaScript served from a common
domain as the resource server" reads:
"For simple system architectures, such as when the JavaScript application is
served
from a domain that can share cookies with the domain of the API (resource
server), it
may be a better decision to avoid using OAuth entirely, and instead use session
authentication to communicate directly with the API."
I can agree that session authentication could be best here, but how was the
user authenticated in order to create the trusted session? Wouldn't
that/shouldn't that still use an oauth flow to collect credentials?
We need to be clear on the distinction between browser based apps that hold the
token(s) in the browser space, vs. those that don't. I agree that with this
"common domain" architecture, the tokens should not be held in the browser, but
it doesn't follow that oauth should not be used at all.
Leo
_______________________________________________ OAuth mailing list
OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
