90°F

Aaron Parecki

  • Articles
  • Notes
  • Photos
  • Nico Kaiser https://twitter.com/nicokaiser   •   May 2
    ... assuming I can control what JS code runs on my site (which is a different problem), this should be safe, right?
    Aaron Parecki
    That's a big assumption (you don't know what browser extensions the user is using) but yes that's one way to be more confident. I wouldn't use absolute terms like "safe" though. "Less risky" maybe.
    San Jose, California • 49°F
    Thu, May 2, 2019 4:31pm -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk you linked to "Insufficient Redirect URI Validation" though? maybe i'm just confused about what you were talking about.

    Aaron Parecki
    Right, that's one way to steal data out of the redirect even if the browser is doing everything right.

    The attacker creates a redirect url at the hostname of the real app but uses an endpoint on the app that can then redirect to the attackers app. Chaining the redirects using an open redirector.
    San Jose, California • 49°F
    1 reply
    Thu, May 2, 2019 4:30pm -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk Yes, i get that, but the attacker can make the access token request just as easily as the legitimate client.

    Aaron Parecki
    No it can't, because the attacker won't have the PKCE secret at that point. (We're talking about the case where the code is stolen out of the redirect through one of many mechanisms)
    San Jose, California • 49°F
    1 reply
    Thu, May 2, 2019 4:26pm -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk no, I understand that one, I just still don't see how pkce helps improper redirect validation (since the pkce secret and redirect URI come from the same request)

    Aaron Parecki
    PKCE makes the auth code useless if it's stolen. In PKCE the secret isn't sent out until the access token request.
    San Jose, California • 49°F
    1 reply
    Thu, May 2, 2019 4:21pm -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk huh? But the redirect_uri is controlled by the same person who controls the code_challenge

    Aaron Parecki
    That particular attack doesn't assume a malicious browser, that one is improper redirect uri validation. I should probably just write up better explanations of all the attacks in that document but they are all described there.
    San Jose, California • 49°F
    1 reply
    Thu, May 2, 2019 4:17pm -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk isn't the section you linked to just as much of a concern under the authorization code flow as the implicit flow? since javascript clients are public clients no matter what?

    Aaron Parecki
    Nope because PKCE solves the problem of the thing being stolen during the redirect.
    San Jose, California • 49°F
    1 reply
    Thu, May 2, 2019 3:39pm -07:00
  • Nico Kaiser https://twitter.com/nicokaiser   •   May 2
    What is your opinion on refresh tokens in client-side apps? The PKCE Auth Code flow allows issuing refresh tokens, so SPAs can refresh their tokens without relying on web_message (possibly cross-domain) iframes. ...
    Aaron Parecki
    Totally depends on your risk tolerance. Browsers are always a more risky environment, so that's something to keep in mind with refresh tokens.

    If you are going to issue refresh tokens to JS, definitely rotate them after every use.
    Sunnyvale, California • 49°F
    1 like
    Thu, May 2, 2019 3:32pm -07:00
  • Sebastian Lasse https://mastodon.social/@sl007   •   May 2

    @aaronpk This could save you 4 characters ;))
    return btoa(encodeURIComponent(str)
    .replace(/%([0-9A-F]{2})/g, (m, p1) => String.fromCharCode(parseInt(('0x'+p1), 16))));

    Aaron Parecki
    hah clever!
    Sunnyvale, California • 49°F
    Thu, May 2, 2019 3:31pm -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk sure, but a malicious browser could also save the entire js state to disk in exactly the same way (and some do a limited version of this for caching purposes). so it's hard for me to think of that as a security benefit? this is only more secure if everyone along the line behaves exactly in the way you expect it to

    Aaron Parecki
    Security is never about stopping 100% of attacks, since that's impossible. It's about mitigating risk, and reducing the attack surface.

    It's worth reading this whole document even if it is a bit terse. Here's a good example of an unexpected attack on the Implicit flow: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12#section-4.1
    Sunnyvale, California • 49°F
    2 replies
    Thu, May 2, 2019 3:30pm -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk but the browser is also the one executing the code that's verifying whether the browser transferred the data correctly? maybe a concrete attack would help me get my head around this better

    Aaron Parecki
    Think of it from the PoV of the thing sending the access token. It wants to make sure the AT ends up in the client and isn't stolen along the way. It can't trust the browser's address bar because the browser isn't the thing it's sending the token to, the code in the browser is.
    Mountain View, California • 49°F
    Thu, May 2, 2019 10:13am -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk but the browser is also the one executing the code that's verifying whether the browser transferred the data correctly? maybe a concrete attack would help me get my head around this better

    Aaron Parecki
    Here's one: The access token is sent in the address bar, so it becomes part of the browser history. This will be written to disk, and possibly even synced to the browser's "cloud" and then even synced down to other devices.
    Mountain View, California • 49°F
    1 reply
    Thu, May 2, 2019 10:07am -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk sorry I guess I should have specified "with https". doesn't https' security model encompass this one?

    Aaron Parecki
    Nope because the browser is still an unknown there, at least from the point of view of the sender of the sensitive data.
    Mountain View, California • 49°F
    1 reply
    Thu, May 2, 2019 9:03am -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk This is a good post! But I'm having trouble trying to understand the attack that the authorization flow is protecting against. How can a token be stolen "in transit back to the application"?

    Aaron Parecki
    Think of it this way: The server is trying to send some sensitive data to the application, but has no direct communication channel, and instead has to trust some other piece of software (the browser) to deliver it.
    Mountain View, California • 49°F
    1 reply
    Thu, May 2, 2019 8:40am -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk This is a good post! But I'm having trouble trying to understand the attack that the authorization flow is protecting against. How can a token be stolen "in transit back to the application"?

    Aaron Parecki
    An easy example to see is captive wifi portals where the network intercepts DNS requests and returns a different answer.
    Mountain View, California • 49°F
    Thu, May 2, 2019 8:33am -07:00
  • alianora https://cybre.space/@nightpool   •   May 2

    @aaronpk This is a good post! But I'm having trouble trying to understand the attack that the authorization flow is protecting against. How can a token be stolen "in transit back to the application"?

    Aaron Parecki
    That's the classic problem with the front-channel (sending data over HTTP redirects in a browser). The sender has no way to know if the receiver got the data, and has no way to tell if it was stolen or copied.
    Mountain View, California • 49°F
    Thu, May 2, 2019 8:31am -07:00
  • Randall Degges https://twitter.com/rdegges   •   May 2
    Just in case you were wondering, there is, in fact, a blockchain magazine for Australians.
    Aaron Parecki
    ohno
    Mountain View, California • 49°F
    Wed, May 1, 2019 7:38pm -07:00
  • Nico Kaiser https://twitter.com/nicokaiser   •   May 1
    From what I understand, the Auth Code flow (even with PKCE) needs some kind of backend in the app (i.e., no static HTML-only cross-domain SPA), or am I missing something?
    Aaron Parecki
    If you read the post I talk about exactly that issue and provide sample code for doing auth code + PKCE entirely in JavaScript
    Mountain View, California, USA • 49°F
    1 reply
    Wed, May 1, 2019 9:58am -07:00
  • Justin Richer https://twitter.com/justin__richer   •   Apr 28
    I've been working on a protocol idea recently, and I've written up some thoughts with strawman examples at https://oauth.xyz/

    It's far from final or complete, but if you're coming to #iiw, come talk to me about it.
    Aaron Parecki
    What's your preferred channel for getting feedback on this? Email? Blog posts? Issues on the site's GitHub repo?

    Also if you're planning on running a session about this at #IIW please hold it on the 2nd or 3rd day since I have to miss the first day!
    Portland, Oregon, USA
    2 likes 1 reply
    Mon, Apr 29, 2019 4:05pm -07:00 #iiw
  • Justin Richer https://twitter.com/justin__richer   •   Apr 29
    California, I am in you! #iiw
    Aaron Parecki
    see you soon!
    Portland, Oregon • 49°F
    Sun, Apr 28, 2019 10:43pm -07:00
  • Apr 26

    About Luminary’s $100 million: many of us are working 7 days a week on a tiny budget to build something we think is important, and Luminary and the like will light VC checks on fire to burn the podcast industry down around them if it means the chance to monetize an open platform.

    Aaron Parecki
    πŸ‘ well said πŸ‘
    Portland, Oregon • 49°F
    Fri, Apr 26, 2019 10:39pm -07:00
older

Hi, I'm Aaron Parecki, Director of Identity Standards at Okta, and co-founder of IndieWebCamp. I maintain oauth.net, write and consult about OAuth, and participate in the OAuth Working Group at the IETF. I also help people learn about video production and livestreaming. (detailed bio)

I've been tracking my location since 2008 and I wrote 100 songs in 100 days. I've spoken at conferences around the world about owning your data, OAuth, quantified self, and explained why R is a vowel. Read more.

  • Director of Identity Standards at Okta
  • IndieWebCamp Founder
  • OAuth WG Editor
  • OpenID Board Member

  • πŸŽ₯ YouTube Tutorials and Reviews
  • 🏠 We're building a triplex!
  • ⭐️ Life Stack
  • βš™οΈ Home Automation
  • All
  • Articles
  • Bookmarks
  • Notes
  • Photos
  • Replies
  • Reviews
  • Trips
  • Videos
  • Contact
© 1999-2025 by Aaron Parecki. Powered by p3k. This site supports Webmention.
Except where otherwise noted, text content on this site is licensed under a Creative Commons Attribution 3.0 License.
IndieWebCamp Microformats Webmention W3C HTML5 Creative Commons
WeChat ID
aaronpk_tv