[HN Gopher] OAuth from First Principles
       ___________________________________________________________________
        
       OAuth from First Principles
        
       Author : n2d4
       Score  : 284 points
       Date   : 2024-09-01 22:03 UTC (4 days ago)
        
 (HTM) web link (stack-auth.com)
 (TXT) w3m dump (stack-auth.com)
        
       | candiddevmike wrote:
       | No mention of JARM unfortunately.
        
       | shreddit wrote:
       | Quite funny they ask "why would you want to reinvent the wheel"
       | when they just did that...
       | 
       | And why do most of these "Auth0" replacements only implement
       | nextjs?
        
         | n2d4 wrote:
         | We gotta start somewhere, and Next.js is popular right now --
         | we're working on some cool non-Next stuff though (eg. auth
         | proxies that can provide user info to any server, which we can
         | hopefully launch within the next weeks).
         | 
         | Regardless, the focus of this blog post is on OAuth, not Stack
         | Auth =) I appreciate the feedback though.
        
           | shreddit wrote:
           | Yes, the blog post is very informative (although the images
           | do not scale well on mobile).
           | 
           | My previous post was based on the phrase "open-source Auth0"
           | (in your blog post) and we use Auth0 (and don't like it). But
           | all of out apps are react, not nextjs
        
             | 3dbrows wrote:
             | I'm currently evaluating Auth0 and other similar services
             | with a view to migrating from Cognito. May I ask what you
             | don't like about it?
        
           | chairmansteve wrote:
           | Thanks for this, I will work through it.
           | 
           | If you happen to be looking for future blog posts:
           | 
           | One thing that would help me and probaby a lot of other
           | people is to show the flow using API calls in Postman.
           | 
           | Currently I am planning to reverse engineer example code in
           | an unfamiliar framework...
        
       | mattgreenrocks wrote:
       | Thank you for writing this up. Helps me understand all the steps
       | and why they exist.
        
         | mannyv wrote:
         | The 'why' is what makes this post good. Lots of posts just saw
         | 'do this.' But to learn you should really know the 'why.'
        
       | 0cf8612b2e1e wrote:
       | This is rendering poorly on my phone. Had to enable desktop mode
       | to see the diagrams which are unwise cut off.
        
         | codetrotter wrote:
         | Some of the pictures stick out beyond the right side of the
         | screen, and scrolling felt slightly sluggish(?), but aside from
         | that I found the page to look pretty ok in Safari on iPhone.
        
         | n2d4 wrote:
         | Thanks for the catch, fixed it now!
        
           | Sn4ppl wrote:
           | Now it looks great
        
       | bgschiller wrote:
       | Nice writeup, this is also how I think about OAuth.
       | 
       | I gave a very similar talk at Develop Denver back in 2018:
       | https://www.youtube.com/watch?v=7rGkz9Ib4fQ
       | 
       | My slides even look similar to your diagrams:
       | https://brianschiller.com/lets-build-oauth/#/31/10
        
       | taeric wrote:
       | I'm still not entirely clear on if I should abandon implicit flow
       | for a static site to get credentials. Easy enough to switch it to
       | the CODE flow, but that gets you a refresh token with AWS and
       | that feels a bit more risky to have on the client side.
        
         | CuriouslyC wrote:
         | You can do stuff to keep the lifetime down on the refresh
         | token.
        
           | taeric wrote:
           | I mean, sure. I can also revoke them and such. Still not
           | clear if that is much better than just doing the implicit
           | flow.
        
             | littlecranky67 wrote:
             | Problem is that Cognito impicit flow wont issue refresh
             | tokens and limits acces token lifetime to 24h
        
               | taeric wrote:
               | Right, but that seems preferable if I'm doing this all
               | client side? Yes, an access token could get leaked in the
               | URL. But sending the refresh token to the client feels
               | far more dangerous.
        
               | littlecranky67 wrote:
               | Yeah but that also means your users will have to re-login
               | every 24h. Other implementations (i.e. Keycloak) issue
               | refresh tokens on the implicit flow.
        
               | taeric wrote:
               | Is it ok practice to store the refresh token in local
               | storage, then?
        
         | candiddevmike wrote:
         | You (typically) only get a refresh token if you ask for offline
         | access in your request scope AFAIK. It's not the default
         | (online is).
        
           | taeric wrote:
           | For AWS Cognito's Token endpoint? Where is that documented?
           | I'm also not seeing that behavior, as I don't have that in my
           | scope and I do get a refresh token if I do the CODE flow.
        
             | candiddevmike wrote:
             | I'm referring to the openid standard I guess[1], it looks
             | like AWS Cognito does something different (they don't
             | support offline_access, but they always issue a
             | refresh_token from what I'm reading).
             | 
             | 1 - https://openid.net/specs/openid-connect-
             | core-1_0.html#Offlin...
        
               | taeric wrote:
               | Yeah, if you do a CODE flow, you get three tokens.
               | Implicit is only access.
               | 
               | They at least have decent support to guard api access
               | using these.
        
         | mooreds wrote:
         | > I'm still not entirely clear on if I should abandon implicit
         | flow for a static site to get credentials.
         | 
         | The answer is to threat model.
         | 
         | What's the risk of an access token falling into the hands of
         | someone who has got malicious JS into your webpage?
         | 
         | If it is a public API or not risky, maybe implicit is okay.
         | 
         | There's more on the attacks and mitigations here:
         | https://fusionauth.io/blog/whats-wrong-with-implicit-grant
        
       | lxe wrote:
       | I haven't really dove deep into oauth flow since 2015 or so until
       | I started working on a little side project choosing to go with
       | AWS Cognito, and the whole PKCE part of the flow was new to me.
       | This explains them well.
        
       | hn_throwaway_99 wrote:
       | I thought it was somewhat funny that all of the points
       | highlighted in the "Attack #1: Big Head's credentials are
       | exposed" section are exactly how Plaid works.
        
         | Spivak wrote:
         | Yep, Plaid is put in a rough position of having to make
         | something work across a bunch of financial institutions that
         | can't or won't enable applications to have secure access.
         | Plaid's existence and popularity is the canary that banks are
         | way behind on features that users want.
        
         | mooreds wrote:
         | This is why I avoid plaid at all costs. Hopefully FAPI and some
         | of the banking open standards will (eventually) help with this.
        
         | tomjakubowski wrote:
         | Not true anymore, at least for some banks. On connecting to
         | Plaid, Chase provides an oauth flow, and Plaid never sees your
         | credentials.
         | 
         | Plaid announced this level of integration with Chase in 2018.
         | Unsure when it was implemented.
         | 
         | https://plaid.com/blog/chase/
        
       | mooreds wrote:
       | Also recommend reading the OAuth Security BCP[0].
       | 
       | Kinda dense and there's bit of jargon, but consolidates person-
       | decades of wisdom around this topic.
       | 
       | 0: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
       | secur...
        
       | racl101 wrote:
       | I would love to learn all architecture lessons in the context of
       | Silicon Valley.
        
         | tonymet wrote:
         | with Bighead, and possibly Jinjiang , exclusively
        
       | rguldener wrote:
       | Very cool! I love how you build on the need for each step one by
       | one.
       | 
       | We implemented (O)Auth for 250+ APIs with Nango and wrote about
       | our experience here: https://www.nango.dev/blog/why-is-oauth-
       | still-hard
        
       | focusedone wrote:
       | This is great!
        
         | michalmiko wrote:
         | 60000ucc
        
       | bcherny wrote:
       | The site seems to have been hugged to death. Does anyone have a
       | mirror link?
        
         | bcherny wrote:
         | In case anyone else needs it: http://archive.today/BxSoe
        
       | ultimoo wrote:
       | If you're building a new SaaS today would you simply implement
       | this natively in your stack or go with a vendor like auth0?
        
         | lknuth wrote:
         | I hve just implemented this after we moved away from
         | SuperTokens. My takeaway is that its easier than you'd think
         | (there are libraries that do interaction with the SSO provider
         | for you) and you can fine tune it to your liking (for example,
         | more involved account linking).
         | 
         | If you're starting out though, probably go for a SaaS in the
         | beginning. But be sure to have monitoring for pricing and an
         | option to close account creation, these things can become
         | expensive fast.
        
           | tgma wrote:
           | I am curious what was your issue with Supertokens?
        
         | kirubakaran wrote:
         | You could use something like
         | https://docs.allauth.org/en/latest/
         | 
         | auth0 is too expensive for new SaaS imho
        
         | pphysch wrote:
         | If you aren't in a rush, it's worth learning and the
         | implementation won't be too big.
        
       | stronglikedan wrote:
       | Man I wish I would have run across this when you first posted the
       | blog. I just spent the last week learning all of this in pieces
       | and by trial and error! Great writeup!
        
       | animal_spirits wrote:
       | I just watched this lecture on Oauth2 and OpenID, good if you
       | prefer video formats
       | 
       | https://www.youtube.com/watch?v=996OiexHze0
        
       | bityard wrote:
       | I love the Silicon Valley references. One of the funniest shows
       | ever made. I don't see it talked about much on HN, maybe it tends
       | to hit a little too close to home?
        
         | TacticalCoder wrote:
         | Both _Silicon Valley_ and _The IT Crowd_ (the british version)
         | are amazing. Although not comedy I also strongly recommend
         | _Halt and Catch Fire_.
        
       | jiggawatts wrote:
       | And this is why it takes me a solid minute to log in to my CRM
       | web app to submit my timesheets for the day, a task that takes
       | only 5 seconds.
        
       ___________________________________________________________________
       (page generated 2024-09-05 23:00 UTC)