Due to the security risks of implicit Grant flow, our Javascript adapter
only supports Auth Code Grant flow. Our IDP has an extra step of
allowing you to specify a valid CORS origin for an application. Anybody
see any problems with this kind of approach? Implicit Grant Flow just
seemed
If you don't have a client secret, or are storing the the client secret in the
Javascrypt, then you are probably more at risk using code than implicit.
Implicit is risky because running a OAuth client in the browser is risky.
Using code in that case makes it no better, and arguably worse.
If you don't have a client secret, why is Javascript-based auth code
grant flow more risky? We also require SSL and valid redirect URI
patterns to be registered for the application. The code can only ever
be sent to specific URLs and can only be used once. CORS origin
validation is also an
You are passing code in a query parameter, and without a secret that is more
likely to be leaked than sending token in the fragment directly from the
authorization endpoint to the browser JS in a fragment.
You have several extra round trips for no security benefit. In your case the
code in
Typically the implicit callback JS is part of the application that is already
loaded and cached in the browser.
The implicit flow doesn’t depend on on the fragment not being re-appended to
the resource location URI in the 302. It would admittedly be more secure if
that didn’t happen.
OK, I don't know if the WG has discussed the issue of fragments in browser
history.
So you are trading off several round trips against the possibility of a token
leaking in browser history or bookmark?
One extension that Connect introduced was a code id_token response type that
is fragment
The following errata report has been submitted for RFC6819,
OAuth 2.0 Threat Model and Security Considerations.
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6819eid=4267
--
Type:
Hi Bill,
I'm not sure if I have permission to post to the OAuth list. Anyway, if your
page that does the OAuth processing includes third party scripts, then those
scripts will probably have access to the code, client secret, and access token.
I believe this concern is addressed in the security
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Dynamic Client Registration Management
Protocol
Authors : Justin Richer
The security problem was people only doing host name matching on redirect_uri
and attackers finding redirectors to use. That impacted all public clients
not just implicit.
Implicit took most of the heat because that was what Facebook was using, and
they had the largest issue.
Connect has a
10 matches
Mail list logo
