<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>dwaite</author><text>Re: OAuth 2, once you carve out everything but the code flow and token refreshes it becomes harder to imagine simplifications that don&amp;#x27;t remove important functionality.&lt;p&gt;The flow becomes &amp;quot;redirect the user to have them authenticate, getting back a code. Make an API call to trade that code in for access. Once access expires, try to refresh it. If refreshing fails, send the user back to re-authenticate.&amp;quot;.&lt;p&gt;The challenge people tend to hit is mistakenly trying to implement broad + reusable code at the start. OAuth 2 is described as a framework (e.g. optional parts and extensions leading to most likely non-interoperable implementations). Without a profile like OpenID Connect Basic Client, this includes a lot of extra work. Once you stop striving to implement generic interoperability in your client (or shoot for a limited profile like OpenID Connect Basic Client), the whole client implementation can fit in &amp;lt; 1 page of code.</text><parent_chain><item><author>modernpacifist</author><text>To answer as best as possible given the vagueness:&lt;p&gt;Cookies: Highly compatible with most if not all browsers (and even headless tools). Lends themselves to having an expiry date and generally best when used with time sort of short-lived expiring session.&lt;p&gt;JWT: Everyone tends to use these in a stateless manner which means once issued, somewhat impossible to revoke without invalidating all JWTs or having a blacklist (and we&amp;#x27;re back at stateful). Plus some implementations had issues with downgrade attacks I think it was...&lt;p&gt;OAuth 1: Fine assuming you could keep clocks in sync and guarantee the secure storage of the keys&amp;#x2F;secrets. Good in that it didn&amp;#x27;t rely on HTTPS but if the secrets ever got compromised then the attacker would have free reign of that account until detected.&lt;p&gt;OAuth 2: Basically a complicated way to get short lived session tokens, potentially from a 3rd party API&amp;#x2F;auth source. Relies entirely on HTTPS to keep data secure in-transit and less of an issue if the session token gets compromised since its ideally short lived (because most want it to be stateless - those who keep a valid list of tokens sometimes skip the token expiry).</text></item></parent_chain></comment><story><title>Ask HN: Cookies vs. JWT vs. OAuth</title><text>I’m using passport.js with a local strategy for authentication, and I’m using sessions&amp;#x2F;cookies for keeping state and keeping the user logged in.&lt;p&gt;I’m not very knowledgeable in security (that’s why I’m asking here), but will using JWT (with the token stored in the cookie) to keep the user logged in  instead of sessions&amp;#x2F;cookies make my application more secure when the passport middleware executes req.isAuthenticated? I thiiink somewhere in that call it checks cookies or jwt, depending on implementation.&lt;p&gt;Also, I do not plan on opening the API to other sites, so OAuth is unnecessary. Is my understanding correct?</text></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>kevlened</author><text>Before going all the way on cookies, make sure to consider whether you&amp;#x27;re creating a mobile app, as mobile apps usually don&amp;#x27;t handle cookies for you automatically. In my experience, OAuth is a bit easier in mobile. If you support cookies for browsers and OAuth for mobile, your API will have to support both authentication methods.</text><parent_chain><item><author>modernpacifist</author><text>To answer as best as possible given the vagueness:&lt;p&gt;Cookies: Highly compatible with most if not all browsers (and even headless tools). Lends themselves to having an expiry date and generally best when used with time sort of short-lived expiring session.&lt;p&gt;JWT: Everyone tends to use these in a stateless manner which means once issued, somewhat impossible to revoke without invalidating all JWTs or having a blacklist (and we&amp;#x27;re back at stateful). Plus some implementations had issues with downgrade attacks I think it was...&lt;p&gt;OAuth 1: Fine assuming you could keep clocks in sync and guarantee the secure storage of the keys&amp;#x2F;secrets. Good in that it didn&amp;#x27;t rely on HTTPS but if the secrets ever got compromised then the attacker would have free reign of that account until detected.&lt;p&gt;OAuth 2: Basically a complicated way to get short lived session tokens, potentially from a 3rd party API&amp;#x2F;auth source. Relies entirely on HTTPS to keep data secure in-transit and less of an issue if the session token gets compromised since its ideally short lived (because most want it to be stateless - those who keep a valid list of tokens sometimes skip the token expiry).</text></item></parent_chain></comment><story><title>Ask HN: Cookies vs. JWT vs. OAuth</title><text>I’m using passport.js with a local strategy for authentication, and I’m using sessions&amp;#x2F;cookies for keeping state and keeping the user logged in.&lt;p&gt;I’m not very knowledgeable in security (that’s why I’m asking here), but will using JWT (with the token stored in the cookie) to keep the user logged in  instead of sessions&amp;#x2F;cookies make my application more secure when the passport middleware executes req.isAuthenticated? I thiiink somewhere in that call it checks cookies or jwt, depending on implementation.&lt;p&gt;Also, I do not plan on opening the API to other sites, so OAuth is unnecessary. Is my understanding correct?</text></story>