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
I've just posted draft updates to the Introspection, Dynamic Registration, and
Dynamic Registration Management drafts in order to update my associated email
address and organization. The introspection update also contains a couple of
typo fixes (thanks to those who found them!).
No other change
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 Protocol
Authors : Justin Richer
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
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 Token Introspection
Author : Justin Richer
Filename: draft-
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
On 2/9/2015 5:03 PM, John Bradley wrote:
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?
Yes, bookmarking tokens is a little scary, IMO
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
For implicit flow, wouldn't the token be available in the browser
history and could also possibly be bookmarked by accident or on purpose?
If a code is bookmarked, so what? It is only valid for a tiny window
(milliseconds).
Please tell me how a code is more likely to be leaked without a clie
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.
Re-appe
The implicit flow depends upon a subtle and little known aspect of
browser behavior - that the URI fragment component isn't propagated
across redirects.
I havent checked this recently - but I am aware that several folks have
found that some browser versions dont comply with this requirement.
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 th
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 e
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.
Perh
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=6819&eid=4267
--
Typ
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 real
16 matches
Mail list logo
