There are two primary aspects of OAuth that are undesirable in this
situation:
1) Using a redirect-based OAuth flow to obtain an access token adds
unnecessary attack vectors to the application (see all the redirect-based
attacks in the Security BCP)
2) Storing the access token somewhere accessible
It would perhaps be better to phrase it as “don’t use OAuth in the JavaScript
application directly” instead of “not entirely”.
— Justin
On Jul 23, 2019, at 12:14 AM, Leo Tohill
mailto:leotoh...@gmail.com>> wrote:
I didn't see the earlier discussion (do you have a date or title?) so apologies
I didn't see the earlier discussion (do you have a date or title?) so
apologies if I'm bringing up something that's been resolved. But I still
think that it's really confusing to say "it
may be a better decision to avoid using OAuth entirely" if the application
will still be using Oauth/OIDC (whi
+1, as discussed before
Hans.
On Mon, Jul 22, 2019, 18:25 Brock Allen wrote:
> 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 p
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 wo
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
