Well - first of all that it uses all the recommend validation techniques
- state validation + protection
- nonce validation
- at_hash validation
- identity token validation
- discovery
+ solid and tested JS code
I don’t see extra value for a JS client in things like “signed requests” -
as I said
+1 I'm with you Aaron. I am not as well versed as other members of this
standard body in OAuth but I would be happy to help build this document
if folks with more experience would help.
- Jim
On 2/17/17 8:05 AM, Aaron Parecki wrote:
> Can you describe the aspects that make a JS client library "s
> Given a solid client library for JS, I think implicit flow is OK to use.
If you can, can you dig deeper here? What is it about this particular
library that makes its use of the OAuth 2 implicit flow secure? Signed
messages? Only supports registered clients? Something else?
Aloha, Jim
On 2/17/
Can you describe the aspects that make a JS client library "solid"? This is
what I think would be useful to see written up in a document like the
Native Apps one.
It's interesting to me that so many of you have independently opted to use
the auth code flow for Javascript apps. I think that's a sig
Given a solid client library for JS, I think implicit flow is OK to use.
But I agree that there are many “home grown” implementation out there that
are not secure - and the necessary JS code to write a good client is not
necessarily the “pit of success”.
You should give this lib a go (it’s also a
+1000
We are currently going through internal turmoil over the usage of implicit
grant for ua-based apps. The webapp case is well understood and the WG has
work in progress to define best practices for native apps. Having one for
ua-based apps would be HUGELY beneficial
On Fri, Feb 17, 2017 a
Thank you to those answering my question on implicit for JS clients.
The responses so far seem to represent what the security world is
saying about the implicit grant - keep away from it other than for a
few OIDC use cases.
Does anyone think it would be valuable to author a brief RFC to give
cle
Same for Deutsche Telekom. Our javascript clients also use code flow with CORS
processing and of course redirect_uri validation.
Best regards
Sebastian
Von: OAuth [mailto:oauth-boun...@ietf.org] Im Auftrag von Bill Burke
Gesendet: Freitag, 17. Februar 2017 00:14
An: oauth@ietf.org
Betreff: Re:
