Used jwt for our web app before - changed to session cookies. To make jwt secure for web apps it feels like you are reinventing session authentication.
Another interesting method, overkill for most applications but absolutely required for end-to-end encrypted apps where no password must be sent to the server (eg: password managers): the Secure Remote Password (SRP) protocol[1].<p>It's a form of zero-knowledge proof-based verification that the password provided during account creation matches the one provided during an authentication challenge, all without transmitting the password at all. As a bonus, it also act as a key exchange on the client and server, that can be used for securing transmissions over untrusted channels (at the cost of having stateful connections).<p>[1] <a href="https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol" rel="nofollow">https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...</a>
Meh. I'm getting a sense that the author's grasp of authentication and authorization protocols is incomplete. I don't mean in the sense that the author left out some popular protocols, which is true, but in the sense that there's details wrong. For example, oauth and OpenID are mentioned only in the context of social login, and the differences between oauth, oauth2, OpenID and OIDC aren't covered (and OIDC is almost entirely unrelated to the original OpenID). Also, the author has a section at the end "GitHub social auth" as if it were somehow different from regular oauth used all over the internet.<p><a href="https://www.wikiwand.com/en/List_of_OAuth_providers" rel="nofollow">https://www.wikiwand.com/en/List_of_OAuth_providers</a>
It makes no sense whatsoever to "compare" Web Authentication methods for humans in 2020 without even mentioning WebAuthn since that's literally why it's called WebAuthn (Web Authentication) and that's exactly what it's for.<p>In one sense this is bad news for this comparison, but it's also bad news for the general state of security on the web, because this item is 8 hours old and I'm writing this top level item now, which means for eight hours people who think of themselves as "web developers" didn't even ask "Why not WebAuthn?"
From the section on session-based authentication:<p><a href="https://tools.ietf.org/id/draft-broyer-http-cookie-auth-00.html" rel="nofollow">https://tools.ietf.org/id/draft-broyer-http-cookie-auth-00.h...</a><p>"To mitigate replay attacks (re-use of a sniffed cookie), the value of the cookie used for authentication SHOULD NOT contain the users credentials but rather a key associated with the authentication session, and <i>this key SHOULD be renewed (and expired) frequently</i>."<p>Session cookies are often defined as cookies that expire when the browser is closed. The truth is that session cookies do not necessarily expire when the browser is closed. Indeed they are lost to the browser, but the user can save them to a text file. If they are truly expired then they should no longer work. However, in some cases, the cookie in the text file can be reused to avoid login, long after after the browser is closed and across subsequent reboots. For example, one such case is a very popular webmail provider. Since the provider now forces users to run Javascript in order to login, this technique can be used to check, read and send mail from the command line using clients that do not include a Javascript interpreter. There are many other examples where session cookies can be used after the browser is closed to avoid having to keep logging in. Unless the website is one that logs the user out after a period of inactivity, there is a good chance "sessions cookies" can be used long-term.
Not mentioned: passwordless authentication<p>See:<p><a href="https://www.microsoft.com/en-us/security/business/identity/passwordless" rel="nofollow">https://www.microsoft.com/en-us/security/business/identity/p...</a><p><a href="https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE2KEup" rel="nofollow">https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE...</a><p>In passwordless authentication, the device creates a public and private key when registered. The private key can only be unlocked using fingerprint or PIN. If an attacker knows the PIN he also needs the device. If he has the device he also needs the PIN.
Good overview, but I'm not sure I agree with the assertion that OAuth/OpenID is unconditionally more secure. It still depends on both the provider and the intermediate site doing things properly, like generating actually random values, not reusing randomness, not leaking tokens, and all the stuff you have to worry about normally.
With the web developer hat on I most prefer working on apps with cookie based authentication since it makes it easy to use the browser to debug/make additional requests. If the cookie already exists I can go to any API url in the browser and it just works. Putting the secret in localstorage or only in app memory makes that not possible.<p>On the API side I prefer to support both cookie and Authorization header so you get the benefits in browser but don't overcomplicate the CLI side of things by requiring cookie state.
>Tokens cannot be deleted. They can only expire. This means that if the token gets leaked, an attacker can misuse it until expiry. Thus, it's important to set token expiry to something very small, like 15 minutes.<p>But can be black listed.
It calls some of these stateless, but don't they all have to run a secondary look-up?<p>For example, in Basic Authentication, you still have to check the username and password against a database, whether that be a file, a relational database, LDAP, etc. For JWT, to verify the signature you must look up the issuer's pre-shared or public key.<p>Is it even possible for a request be stateless if it requires authentication?
Hey auth gurus! I have a newb question for a scenario that this article doesn't appear to cover, so I hope folks don't mind if I ask it here.<p>Is there any way to authorize a front-end app to use private back-end services without requiring a login? (I have people abusing APIs which were intended to be private, and which may otherwise force me to require user accounts.)
Coincidentally, just yesterday I was looking for the usual simple in-server form&session Web site authn functionality for a Rust Web framework (and, ideally, also client certs).<p>I was confused by what this page says is available, and what it didn't: <a href="https://www.arewewebyet.org/topics/auth/" rel="nofollow">https://www.arewewebyet.org/topics/auth/</a><p>I get why OAuth2/OpenID is popular, in a tech professional environment comfortable with leaking information about users, and also desensitized to the risks of a single Web site having numerous third-party service&CDN dynamic dependencies for a page load... but I still expected the basic default authn mechanism to be form&session, and then some of the other mechanisms to build upon some of the same authn (and perhaps autho) session&events&UX foundation.
Session based auth is what we used to do in the olden days. It was horrible. Sure it was easy to log in a keep a session cookie, but man... restarting servers = logged out, unless you persisted sessions. Session replication. It adds all sort of complexities after the initial implementation.
I use hybrid basic and cookie auth in my application.<p>Basic auth functions as a captcha and invite code, eliminating users not invited and almost all bots.<p>After that,s done, the user gets a cookie (and a private key in LocalStorage) and is not prompted next time.<p>The beauty of cookies and basic is that the cookie is sent before auth takes place.
> Session-based Auth<p>> It's stateful. The server keeps track of each session on the server-side. The session store, used for storing user session information, needs to be shared across multiple services to enable authentication. Because of this, it doesn't work well for RESTful services, since REST is a stateless protocol.<p>What stops you from keeping the JWT token in there? In fact, I doubt that it's some random session ID and not some encrypted payload that gets decrypted instead of looking it up in the database.
It seems like for simple 2-party exchanges, as soon as you are using TLS and assuming you trust it, I'm not sure what the advantage is of doing anything more than basic authentication? Perhaps if you want to throttle authentications to prevent brute forcing it becomes a problem.<p>For sure, if you have more complex auth needs (more parties, granular access, etc etc) then you can start to justify more complex things ... but I'm curious what other weaknesses are there in that scheme?
I find it amusing that this article starts off explaining the difference between authN and authZ and then immediately proceeds to a describe an authN scheme where the authN transaction utilizes a request header called "Authorization" (used in reply to a response header that doesn't have this quirk, oddly enough). Would be nice to see a footnote apologizing for what I'd consider a linguistic blunder on par with "Referer"...
Basic Authentication is a pain with a web app sitting behind Apache as it strips all "sensitive" headers before passing along the request to the web app.
For Digest the article says "Credentials must be sent with every request"... but not really. Once you're logged in the server can remember that you are and not ask for it each time. The client can only send it when requested.
What’s everyone’s preferred auth library for NodeJS based server use? It’ll be interacting with both a React based front-end from desktop as well as a SwiftUI front end from mobile.
> <i>Vulnerable to CSRF attacks</i><p>Is this really still an issue with cookies?<p>We now have cookie options like same-site and secure which AFAIK prevent the vast majority of attacks.