5 ms·

I would add: - Don't build your CI/CD pipelines; use Vercel or something similar - Don't use message queues, crons and anything that can by design cause race

I would add: - Don't build your CI/CD pipelines; use Vercel or something similar - Don't use message queues, crons and anything that can by design cause race conditions until absolutely unavoidable - Use a framework if you and your team know one well (e.g. Django Rest Framework), otherwise use whatever you know inside out even if it doesn't have all the features you need - or you'll end up slowing down painfully at every other complex bug - Using TypeScript for both backend, frontend and the domain simplifies a bunch of things (configuration, types) - Unless you're building ML pipelines in parallel to a web app (or some similar clear technological separations exist, e.g. web interface and an UE5 game), you should use one programming language. All your developers should know the app A-Z in the early stages. - Your product is unlikely to succeed overnight but likely to die because of overengineering. You should worry about scaling, but only a little bit. - Forget using JWTs if you're in some sort of regulated field. Any sensible white/greybox certification for insurance (and that's often a requirement for running a business) will require you to have "log out all devices" option.

cybrox 3y ago
On a project I worked on, we implemented a "log out all devices" option and similar security features by building a simple deadline system on top of using JWTs. Every user's data contained among other things a deadline timestamp, which was (re)set every time a security relevant data point was changed (password, 2FA, log out all devices, etc...) When authenticating a user, services would check for both the JWTs validity (iat, nbf, exp), as well as the cached deadline (iat >= deadline) using a shared auth library. I'd be happy to learn more about the downsides but for as long as this was in place, it has worked really well.
- Zetice 3y ago
  The whole point of JWTs is to not check some other value in the backend. Once you're doing that you've lost the major value of JWTs. So yeah, once you start doing DB calls for every. single. request. you're going to have a lot more options, but JWTs are meant to avoid that. My understanding is the "right" way to do this is to maintain a CRL.
  - michaelsalim 3y ago
    What is CRL supposed to stand for? Google only gave me "Certificate revocation list" which doesn't sound right.
    - Zetice 3y ago
      Yep that's it; JWTs are signed, that's how they work.
      - AntonCTO 3y ago
        Don't forget that a single certificate is used to sign multiple JWTs. Revoking a certificate (let alone communicating it) will revoke all signed JWTs, not just the specific user's.
  - AntonCTO 3y ago
    Yes, it is good if you can avoid checks, and in most cases you can. But in practice it doesn't matter very much: - Scaling is rarely the problem. I never experienced it myself. The same goes for the session. - The complexity can be hidden behind a library. Iirc there is even a specification for this. - You have other advantages because you usually use JWT with OAuth2.x/OIDC in the SSO context. - You benefit from standardization. CRL is probably not going to help you. At least I have no idea. But jti's blacklist will. Don't forget - you still have to maintain and distribute it, which probably won't lead to a better implementation.
    - preseinger 3y ago
      scaling auth infra is basically the entire motivation for things like JWTs if you don't care about every request making an auth check, that's great! then just use basic sessions or whatever. there's no reason to use anything more complex
  - febusravenga 3y ago
    And what parent post described is functionally equivalent to CRL it's a list of user (id, earliestValidTokenTimestamp) which for case of invalidating all sessions on demand serves same purpose. The only major problem is timely sync of those lists in all clients. Same problem as with CRLs, but probably lighter. And of course with other set of limitations.
Zetice 3y ago
Agree with most of this, but not sure about a few points here: > Don't build your CI/CD pipelines; use Vercel or something similar Why wouldn't you build your own CI/CD pipelines early? It's kind of trivially easy to do early on, and in my experience won't really change until/unless you want it to. > Don't use message queues, crons and anything that can by design cause race conditions until absolutely unavoidable Message queues are not universally the cause of race conditions, you just have to accept the eventually-correct nature of the resulting system. If you know how to handle that, you're fine. > Forget using JWTs if you're in some sort of regulated field. Any sensible white/greybox certification for insurance (and that's often a requirement for running a business) will require you to have "log out all devices" option. JWTs didn't stop us from getting SOC Type I and II certified, or prevent us from getting insurance, not sure what you mean by this. I guess we're not in a "regulated field" but if you aren't, JWTs are great.
- AntonCTO 3y ago
  > JWTs didn't stop us from getting SOC Type I and II certified, or prevent us from getting insurance, not sure what you mean by this. What he probably means is that JWT can't be invalidated on its own like you can with a session. But of course it can be done in a similar way, and some products support it. You just lose some of the benefits of JWT. (Let alone the ability to negotiate the logout time span).
  - Zetice 3y ago
    Yeah, I just think folks overestimate the value of a "log out of all devices" button. Short TTLs on session tokens seem fine enough for the early months, at least, and then yeah once you can get that first round of funding (or revenue to pay for the lights), getting something like auth0 might make more sense.
    - gpjanik 3y ago
      I agree with you, but that's one of the things that will have to be rewritten if you're in a regulated business - unless you go for some hybrid "JWT but stored in the database" which is, basically, not a JWT.
koromak 3y ago
CI/CD ended up being probably the easiest and most beneficial part of the process for me. Really doesn't take long to get a good system going.
drowsspa 3y ago
> Don't build your CI/CD pipelines; use Vercel or something similar I'd give exactly the opposite advice. Being able to properly debug your CI/CD code, or even run locally, has been a godsend when you're starting up.
- JonChesterfield 3y ago
  I haven't met vercel. Hudson, buildbot, in house thing built from scratch for some reason - all bad associations here. A CI / deployment pipeline that you can't run locally is absolutely a disaster. You end up building different code to prod, in different fashion, and generally hoping that bugfixes to the local one will be meaningful in the CI one. Buildbot calling a top level makefile that does everything, fine. Some java thing that is configured through a web gui and thus can never be restarted if it ever disappears, not fine. I love the idea of CI and loathe every instance I have ever used.
  - gpjanik 3y ago
    I agree with you, however modern services (like Vercel) solve those problems pretty well. They provide you with the CI you'd otherwise write by yourself.
- gpjanik 3y ago
  There should be no CI/CD code - build the product instead. Fundamentally, outsource devops to some service. Use Firebase, Vercel, etc. Building proper multi-environment CI/CD is where you're doing devops with the belief you're going to be "better at it" with "more control", eventually writing code nobody asked you for.

cybrox 3y ago

On a project I worked on, we implemented a "log out all devices" option and similar security features by building a simple deadline system on top of using JWTs. Every user's data contained among other things a deadline timestamp, which was (re)set every time a security relevant data point was changed (password, 2FA, log out all devices, etc...) When authenticating a user, services would check for both the JWTs validity (iat, nbf, exp), as well as the cached deadline (iat >= deadline) using a shared auth library. I'd be happy to learn more about the downsides but for as long as this was in place, it has worked really well.

Zetice 3y ago
The whole point of JWTs is to not check some other value in the backend. Once you're doing that you've lost the major value of JWTs. So yeah, once you start doing DB calls for every. single. request. you're going to have a lot more options, but JWTs are meant to avoid that. My understanding is the "right" way to do this is to maintain a CRL.
- michaelsalim 3y ago
  What is CRL supposed to stand for? Google only gave me "Certificate revocation list" which doesn't sound right.
  - Zetice 3y ago
    Yep that's it; JWTs are signed, that's how they work.
    - AntonCTO 3y ago
      Don't forget that a single certificate is used to sign multiple JWTs. Revoking a certificate (let alone communicating it) will revoke all signed JWTs, not just the specific user's.
- AntonCTO 3y ago
  Yes, it is good if you can avoid checks, and in most cases you can. But in practice it doesn't matter very much: - Scaling is rarely the problem. I never experienced it myself. The same goes for the session. - The complexity can be hidden behind a library. Iirc there is even a specification for this. - You have other advantages because you usually use JWT with OAuth2.x/OIDC in the SSO context. - You benefit from standardization. CRL is probably not going to help you. At least I have no idea. But jti's blacklist will. Don't forget - you still have to maintain and distribute it, which probably won't lead to a better implementation.
  - preseinger 3y ago
    scaling auth infra is basically the entire motivation for things like JWTs if you don't care about every request making an auth check, that's great! then just use basic sessions or whatever. there's no reason to use anything more complex
- febusravenga 3y ago
  And what parent post described is functionally equivalent to CRL it's a list of user (id, earliestValidTokenTimestamp) which for case of invalidating all sessions on demand serves same purpose. The only major problem is timely sync of those lists in all clients. Same problem as with CRLs, but probably lighter. And of course with other set of limitations.

Zetice 3y ago

Agree with most of this, but not sure about a few points here: > Don't build your CI/CD pipelines; use Vercel or something similar Why wouldn't you build your own CI/CD pipelines early? It's kind of trivially easy to do early on, and in my experience won't really change until/unless you want it to. > Don't use message queues, crons and anything that can by design cause race conditions until absolutely unavoidable Message queues are not universally the cause of race conditions, you just have to accept the eventually-correct nature of the resulting system. If you know how to handle that, you're fine. > Forget using JWTs if you're in some sort of regulated field. Any sensible white/greybox certification for insurance (and that's often a requirement for running a business) will require you to have "log out all devices" option. JWTs didn't stop us from getting SOC Type I and II certified, or prevent us from getting insurance, not sure what you mean by this. I guess we're not in a "regulated field" but if you aren't, JWTs are great.

AntonCTO 3y ago
> JWTs didn't stop us from getting SOC Type I and II certified, or prevent us from getting insurance, not sure what you mean by this. What he probably means is that JWT can't be invalidated on its own like you can with a session. But of course it can be done in a similar way, and some products support it. You just lose some of the benefits of JWT. (Let alone the ability to negotiate the logout time span).
- Zetice 3y ago
  Yeah, I just think folks overestimate the value of a "log out of all devices" button. Short TTLs on session tokens seem fine enough for the early months, at least, and then yeah once you can get that first round of funding (or revenue to pay for the lights), getting something like auth0 might make more sense.
  - gpjanik 3y ago
    I agree with you, but that's one of the things that will have to be rewritten if you're in a regulated business - unless you go for some hybrid "JWT but stored in the database" which is, basically, not a JWT.

koromak 3y ago

CI/CD ended up being probably the easiest and most beneficial part of the process for me. Really doesn't take long to get a good system going.

drowsspa 3y ago

> Don't build your CI/CD pipelines; use Vercel or something similar I'd give exactly the opposite advice. Being able to properly debug your CI/CD code, or even run locally, has been a godsend when you're starting up.

JonChesterfield 3y ago
I haven't met vercel. Hudson, buildbot, in house thing built from scratch for some reason - all bad associations here. A CI / deployment pipeline that you can't run locally is absolutely a disaster. You end up building different code to prod, in different fashion, and generally hoping that bugfixes to the local one will be meaningful in the CI one. Buildbot calling a top level makefile that does everything, fine. Some java thing that is configured through a web gui and thus can never be restarted if it ever disappears, not fine. I love the idea of CI and loathe every instance I have ever used.
- gpjanik 3y ago
  I agree with you, however modern services (like Vercel) solve those problems pretty well. They provide you with the CI you'd otherwise write by yourself.
gpjanik 3y ago
There should be no CI/CD code - build the product instead. Fundamentally, outsource devops to some service. Use Firebase, Vercel, etc. Building proper multi-environment CI/CD is where you're doing devops with the belief you're going to be "better at it" with "more control", eventually writing code nobody asked you for.