The Copenhagen Book: general guideline on implementing auth in web applications

If I&#x27;m not mistaken, this is written by the author of Lucia, a popular auth library for TypeScript [0]. He recently announced that he will be deprecating the library and be replacing it with a series of written guides [1], as he no longer feels that the Lucia library is an ergonomic way of implementing auth. He posted an early preview of the written guide [2] which I found enjoyable to read and complements The Copenhagen Book nicely.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;lucia-auth&#x2F;lucia">https:&#x2F;&#x2F;github.com&#x2F;lucia-auth&#x2F;lucia</a><p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;lucia-auth&#x2F;lucia&#x2F;discussions&#x2F;1707">https:&#x2F;&#x2F;github.com&#x2F;lucia-auth&#x2F;lucia&#x2F;discussions&#x2F;1707</a><p>[2] <a href="https:&#x2F;&#x2F;lucia-next.pages.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lucia-next.pages.dev&#x2F;</a>

This is wrong:<p>&gt; Email addresses are case-insensitive.<p>From <a href="https:&#x2F;&#x2F;thecopenhagenbook.com&#x2F;email-verification" rel="nofollow">https:&#x2F;&#x2F;thecopenhagenbook.com&#x2F;email-verification</a><p>The email standard says they are case sensitive.<p>If you lowercase emails during send operations, the wrong person may get the email. That&#x27;s bad for auth.<p>Some (many) popular email providers choose to offer only case-insensitive emails. But a website about general auth should recommend the general case.<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;9807909&#x2F;are-email-addresses-case-sensitive" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;9807909&#x2F;are-email-addres...</a><p>Side remark: It is not always clear&#x2F;obvious what&#x27;s the other case of a given character is, and may change over time. For example, the German capital ß was added in 2008 to Unicode. So it&#x27;s best to avoid case sensitivity where you can, in general programming.

Wow, this is very nice. One of my pet peeves is how 90% of security resources seem designed to be absolutely inscrutable by non-security experts - especially anything from cryptography. Every single page in here however is clear, concise, to the point, and actionable, love it! (except the one on elliptic curves, which I find about as incomprehensible as most crypto resources).

Would be nice to see alternative documents for similar topics (e.g. something like OWASP Cheatsheet but from more practical point of view).<p>With all the respect, I&#x27;m a bit skeptical about this document for such reasons:<p>- Name is quite pompous. It&#x27;s a very good marketing trick: calling some document like if it was written by group of researchers from a Copenhagen university. :)<p>Yes, Lucia is a relatively popular library but it doesn&#x27;t mean that it is promoting best practices and that its author should be considered an authority in such important field unless opposite is proven.<p>- I don&#x27;t like some aspects of Lucia library design: when user token is almost expired - instead of generating new security token Lucia suggesting just to extend life of existing one. I see it as a very insecure behavior: token lives forever and can be abused forever. This violates one of the security best practices of limited token lifetime.<p>But both Lucia and &quot;Copenhagen Book&quot; encourages this practice [1]:<p>``` if time.Now().After(session.expiresAt.Sub(sessionExpiresIn &#x2F; 2)) { session.ExpiresAt = time.Now().Add( updateSessionExpiration(session.Id, session.ExpiresAt) } ```<p>[1]: <a href="https:&#x2F;&#x2F;thecopenhagenbook.com&#x2F;sessions#session-lifetime" rel="nofollow">https:&#x2F;&#x2F;thecopenhagenbook.com&#x2F;sessions#session-lifetime</a>

There are two things that everybody misses about OAuth and they fly under the radar.<p>Nice to hear someone touch on one of them: you absolutely NEED to use a transaction as a distributed locking mechanism when you use a token.<p>This goes double&#x2F;quadruple for refresh tokens. Use the same token more than once, and that user is now signed out.<p>It doesn&#x27;t matter if your system runs on one machine or N machines; if you have more than one request with a refresh token attached in flight at once - happens all the time - you are signing out users, often via 500.<p>Refresh tokens are one-time use.<p>The other thing devs and auth frameworks miss is the &quot;state&quot; parameter.

I wish more websites would grant you the option to say &quot;I never want my session to expire until I log out, I understand the risks&quot;. The &quot;remember me&quot; button does nothing these days.<p>I&#x27;m so tired of having my day constantly interrupted by expiring sessions. GitHub is my least favourite; I use it ~weekly, so my sessions always expire, and they forced me to use 2FA so I have to drag my phone out and punch in random numbers. Every single time.<p>As well as being terrible UX, though I have no evidence to back this up, I&#x27;m pretty sure this constant logging in fatigues users enough to where they stop paying attention. If you log into a site multiple times a week, it&#x27;s easy for a phishing site to slip into your 60th login. Conversely if you&#x27;ve got an account that you never need to log into, it&#x27;s going to feel really weird and heighten your awareness if it suddenly does ask for a password.<p>Regardless, companies should learn that everyone has a different risk appetite and security posture, and provide options.<p>Side-note, Github&#x27;s constant session expiry &amp; 2FA annoyed me so much that I moved to Gitea and disabled expiry. That was 90% of the reason I moved. It&#x27;s only available on my network too, so if anything I feel I gained on security. Companies 100% can lose customers by having an inflexible security model.

Nice.<p>I recently learned about the SRP protocol [1], and I’m surprised that it’s not more widely used&#x2F;mentioned: with a relatively simple protocol, you can do a ZKP and generate a session token between the server and client in one fell swoop.<p>[1]: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Secure_Remote_Password_protocol" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Secure_Remote_Password_protoco...</a>

Just chiming in that I appreciate this resource. A lot of security advice is esoteric and sometimes feels ridiculous. Like a lawyer who advises you not to do anything ever. This guide was refreshingly concise, easy to follow and understand, and has good straight forward advice.<p>I&#x27;ll keep an eye on these comments to see if there are any dissenting opinions or caveats but I know I&#x27;ll be reviewing this against my own auth projects.<p>One thing I would like to see would be a section on JWT, even if it is just for them to say &quot;don&#x27;t use them&quot; if that is their opinion.

By “auth” do they mean “authn” (authentication) or “authz” (authorization)?<p>It looks like they mean authentication but it would be nice if they were clear.

Somewhat related, I have a short rant about embedded browsers killing the web.<p>Embedded browsers make it impossible (literally in some cases, figuratively in others) to use social OAuth. If you click a link on Instagram, which by default opens in Instagram&#x27;s browser, and that link has &quot;Sign in with Google&quot;, it simply will not work, because Google blocks &quot;insecure browsers&quot;, which Instagram is one. There are even issues getting &quot;Sign in with Facebook&quot; to work, and Meta owns Instagram and Facebook! The Facebook embedded browser suffers from similar issues.

What is the rationale behind the following?<p>&gt; When comparing password hashes, use constant time comparison instead of ==.<p>If you were comparing plaintext you&#x27;d get some info, but it seems overly cautious when comparing salted hashes. Maybe anticipating an unknown vulnerability in the hash function?

Good stuff. The model of &quot;how to build&quot; vs. &quot;library that does&quot; is a good idea when there&#x27;s combinatorial explosion and you want to reduce the design space.<p>At a previous employer, people built some tool that auto-built Kube manifests and so on. To be honest, I much preferred near raw manifests. They were sufficient and the tool actually added a larger bug space and its own YAML DSL.

Anyone know why it&#x27;s called the Copenhagen Book?

I was just reading this and was gonna recommend it to a friend! Saw the announcement from Lucia moving to a resource-based repo and digging deeper saw The Copenhagen Book, which IMHO is the best resource Auth-related I&#x27;ve seen in my 10+ years of career, all very well put together.<p>Two tradeoffs I see is that it is a bit abstract, and also a bit brief&#x2F;succinct in some places where it just says it as it is and not the why. But neither of those are really negatives on my book, just concessions you have to make when doing a project like this. You can dig deeper in any topic, and nowadays libraries have pretty good practical setups, so as a place where it is all bound together as a single learning resource is AMAZING. I&#x27;m even thinking of editing it and printing it!

&gt; CSRF protection must be implemented when using cookies, and using the SameSite flag is not sufficient.<p>Also when it&#x27;s set to strict? Or if it requires a PUT or other method that doesn&#x27;t work with top-level navigation? Is it about ancient or obscure browsers that didn&#x27;t&#x2F;don&#x27;t implement it (<a href="https:&#x2F;&#x2F;caniuse.com&#x2F;same-site-cookie-attribute" rel="nofollow">https:&#x2F;&#x2F;caniuse.com&#x2F;same-site-cookie-attribute</a>)?

This looks ver useful if you&#x27;re about to implement an Auth system. But I thinks it&#x27;s worth noting that many things can be offered without authentication, i.e. without an account. I think it&#x27;s worth noting that e.g. e-commerce can be (and in some rare but appreciated cases is) offered in &quot;guest mode&quot;. Especially for smaller or more niche shops where return customers are less frequent, it&#x27;s just good to keep that in mind.

It’s nice to see something other than “don’t roll your own, it’s dangerous.”<p>I especially appreciated the note that while UUIDv4 has a lot of entropy, it’s not guaranteed to be cryptographically secure per the spec. Does it matter? For nearly all applications, probably not, but people should be aware of it.

It doesn&#x27;t talk about ID tokens and JWT etc with the API only security&#x2F;use case?

you only need to roll your own auth once and you can drop it in anywhere

I wonder why they recommend hashing server tokens in some cases. Is it so that someone who can read the database can’t hijack an account? Or am I misunderstanding why hashing is used?

Well, web applications are not web sites, as the latest would support authentification for noscript&#x2F;basic (x)html browsers.

This is a great guide, thanks.

Great guide, thank you.

- Passwords must be at least 8 characters long....<p>- Use libraries like zxcvbn to check for weak passwords.<p>These rules might be good for high-security sites, but it&#x27;s really annoying to me when I have to generate a length-15 string password with special characters and uppercase for some random one-off account that I use to buy a plane ticket or get reimbursed for a contact lens purchase.

i see that most examples are implemented in golang, if possible would also request the author to consider adding python and node.js snippets

What&#x27;s with the name?

I like it but and I know it’s nit picky- is there a off or other book like thing one can “hold”

If you&#x27;re doing auth in 2024, please consider not supporting passwords. Most people will never use a password manager, and even if they did it&#x27;s not as secure as key-based approaches or OAuth2.<p>Obviously there are exceptions