5 ms·

To add to that, even if you have microservices everywhere on the backend, JWT is still rarely a good choice. Those services are typically exposed to customers v

by hbrn 4y ago

To add to that, even if you have microservices everywhere on the backend, JWT is still rarely a good choice. Those services are typically exposed to customers via some sort of API Gateway/BFF. So if your clients don't speak to microservices directly, authentication between those services could easily be done via plain old HTTP Basic Auth. Stripe has been doing that for their public API since forever, and that's one of the big reasons why it is so easy to work with them.

tobyjsullivan 4y ago
It's worth noting this coconut pattern (hard auth facade, soft interior), while popular and helpful for dev efficiency, is a weak security practice. Using simple pre-shared keys between internal services excludes any meaningful access controls over user data. Whether that's important depends on the domain. For stripe, though, I'm surprised they wouldn't want to ensure internal data requests are being made on behalf of customers who should actually have access to the data. Also, for bigger companies (although, why not smaller ones?), you hit a point where you can't keep blindly trusting every service. Better to have internal security controls. As for when these tradeoffs are appropriate, hard to say. But a good rule of thumb could be when the product is big enough to need an SOA.
- hbrn 4y ago
  > As for when these tradeoffs are appropriate, hard to say And that is my biggest problem. If you don't know whether you need something, you don't need it. Or you just don't have enough expertise to understand why you need it, but that means you will implement it the wrong way anyway.
  - marcosdumay 4y ago
    > If you don't know whether you need something, you don't need it. That's a bad approach for security. Starting with the solution is the wrong way to do it, but you certainly need to actively look if you have problems.
    - hbrn 4y ago
      Let's say you're a startup that's hiring it's 5th engineer. Should you do criminal background checks? Install spyware on laptops? Forbid hiring from other countries? Restrict developer access to production env? Invest all your development time into security features until you run out of those? If you actively look for problems, you will justify all of those. Security is not about knowing which problems exist and fixing them all. It's about knowing which risks are acceptable at your current stage. If you don't know which risks are acceptable, applying random security practices is worse than no security at all. At least when there's no security you are aware of it. If you can't come up with an attack vector where HTTP Basic Auth causes significant problems, you don't need JWT to secure communication. And even if you can come up with an attack vector, is it really easiest one to execute? Speaking of attack vectors, how many of the folks that use JWT for inter-service communication actually rotate encryption keys when anyone who has access to them leaves the company? My bet is very few.
    - P5fRxh5kUvp2th 4y ago
      Why do security people think security trumps everything? It's a serious question. As time goes on I more and more land on the side of Linus Torvalds wrt to security. It kills me the amount of stupid shit I've seen done in the name of security. If security people were to come up with driving standards, no one would be allowed to turn left because it's more dangerous then turning right.
- schwap 4y ago
  Ironically, authorization downstream of an API gateway is an application that JWTs are a good candidate for.
dwaite 4y ago
You have different approaches of security depending on your desire for risk mitigation. Examples (with somewhat made-up names); 1. An ingress moat - your ingress makes decisions on whether someone should be allowed in, after which internally anything goes. 2. Two-stage auth - building on top of the above, internal messages need authentication/authorization for communication channels to be established. This might be basic, x509, kerberos, or federation-based protocols. Microservices environments might use SPIFFE for this. 3. Messenger auth - in addition to the above, requests need to show evidence of direct/indirect interaction with the parties involved. For example, an access JWT may be sent around since it would provide indication of a user and tenant. 4. Intermediary-authorization - a variation of the above, evidence is required on each communication channel 'hop' that the initiator(s) are authorized to make the request against a service. This may involve more centralized services to create many opaque/integrity-protected authorization decisions from an external systems view. 5. Transactional auth - another variation of 3, evidence is required specifically that a given action is authorized, including parties and potentially parameters. This might be sent directly from the original initiating party, or may be created for internal systems close to the ingress point. Note that for a service with a public API, all of these can hypothetically look identical. However, once you get to a certain amount of internal authorization checks, you naturally start to try to represent those with integrity-protected stateless tokens to avoid needing a massive centralized system with low latency consistency and high uptime needs. OAuth access and refresh tokens were designed to help there.

by hbrn 4y ago

tobyjsullivan 4y ago

It's worth noting this coconut pattern (hard auth facade, soft interior), while popular and helpful for dev efficiency, is a weak security practice. Using simple pre-shared keys between internal services excludes any meaningful access controls over user data. Whether that's important depends on the domain. For stripe, though, I'm surprised they wouldn't want to ensure internal data requests are being made on behalf of customers who should actually have access to the data. Also, for bigger companies (although, why not smaller ones?), you hit a point where you can't keep blindly trusting every service. Better to have internal security controls. As for when these tradeoffs are appropriate, hard to say. But a good rule of thumb could be when the product is big enough to need an SOA.

hbrn 4y ago
> As for when these tradeoffs are appropriate, hard to say And that is my biggest problem. If you don't know whether you need something, you don't need it. Or you just don't have enough expertise to understand why you need it, but that means you will implement it the wrong way anyway.
- marcosdumay 4y ago
  > If you don't know whether you need something, you don't need it. That's a bad approach for security. Starting with the solution is the wrong way to do it, but you certainly need to actively look if you have problems.
  - hbrn 4y ago
    Let's say you're a startup that's hiring it's 5th engineer. Should you do criminal background checks? Install spyware on laptops? Forbid hiring from other countries? Restrict developer access to production env? Invest all your development time into security features until you run out of those? If you actively look for problems, you will justify all of those. Security is not about knowing which problems exist and fixing them all. It's about knowing which risks are acceptable at your current stage. If you don't know which risks are acceptable, applying random security practices is worse than no security at all. At least when there's no security you are aware of it. If you can't come up with an attack vector where HTTP Basic Auth causes significant problems, you don't need JWT to secure communication. And even if you can come up with an attack vector, is it really easiest one to execute? Speaking of attack vectors, how many of the folks that use JWT for inter-service communication actually rotate encryption keys when anyone who has access to them leaves the company? My bet is very few.
  - P5fRxh5kUvp2th 4y ago
    Why do security people think security trumps everything? It's a serious question. As time goes on I more and more land on the side of Linus Torvalds wrt to security. It kills me the amount of stupid shit I've seen done in the name of security. If security people were to come up with driving standards, no one would be allowed to turn left because it's more dangerous then turning right.
schwap 4y ago
Ironically, authorization downstream of an API gateway is an application that JWTs are a good candidate for.

dwaite 4y ago

You have different approaches of security depending on your desire for risk mitigation. Examples (with somewhat made-up names); 1. An ingress moat - your ingress makes decisions on whether someone should be allowed in, after which internally anything goes. 2. Two-stage auth - building on top of the above, internal messages need authentication/authorization for communication channels to be established. This might be basic, x509, kerberos, or federation-based protocols. Microservices environments might use SPIFFE for this. 3. Messenger auth - in addition to the above, requests need to show evidence of direct/indirect interaction with the parties involved. For example, an access JWT may be sent around since it would provide indication of a user and tenant. 4. Intermediary-authorization - a variation of the above, evidence is required on each communication channel 'hop' that the initiator(s) are authorized to make the request against a service. This may involve more centralized services to create many opaque/integrity-protected authorization decisions from an external systems view. 5. Transactional auth - another variation of 3, evidence is required specifically that a given action is authorized, including parties and potentially parameters. This might be sent directly from the original initiating party, or may be created for internal systems close to the ingress point. Note that for a service with a public API, all of these can hypothetically look identical. However, once you get to a certain amount of internal authorization checks, you naturally start to try to represent those with integrity-protected stateless tokens to avoid needing a massive centralized system with low latency consistency and high uptime needs. OAuth access and refresh tokens were designed to help there.