GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-10-12) - page 1 of 10
 
___________________________________________________________________
Securing Microservices
42 points by prabaths
https://medium.facilelogin.com/securing-microservices-with-oauth...
___________________________________________________________________
 
t1o5 - 1 hours ago
The article has pretty much summarized security, but did not talk
about JWT revocation techniques. Some may argue that short lived
JWTs do not need revocation and will expire and the refresh of the
token can be blocked by authorization server. But what about long
lived JWTs ? For mobile apps which logins once and keeps the login
unless explicit logout. In cases such as those, how do we revoke a
rogue JWT ?
 
  ianstormtaylor - 53 minutes ago
  I think this is the biggest drawback to "stateless" JWT's that
  most people gloss over when championing. If you need to be able
  to revoke stateless JWT's, you probably shouldn't be using
  stateless JWT's in the first place, because you'll have to re-add
  state to the system to handle revocations. And at  that point why
  not just go with the simpler mental model in the first place.And
  since giving users (or you) the option to "log themselves out of
  other computers" on a fine-grained basis is often an important
  feature to provide, it essentially means stateless JWT's aren't a
  great solution for sessions in most web apps.That's just what
  I've gathered personally. If anyone has a counter argument for
  this case I'd love to hear it!
 
    zeveb - 21 minutes ago
    > If you need to be able to revoke stateless JWT's, you
    probably shouldn't be using stateless JWT's in the first place,
    because you'll have to re-add state to the system to handle
    revocations. And at that point why not just go with the simpler
    mental model in the first place.Because you can speed up the
    normal app path by using stateless access tokens and only
    require online validation to issue new access token.> And since
    giving users (or you) the option to "log themselves out of
    other computers" on a fine-grained basis is often an important
    feature to provide, it essentially means stateless JWT's aren't
    a great solution for sessions in most web apps.The 'stateless'
    tokens may have arbitrarily short lifetimes, e.g. one or five
    minutes.An app may issue multiple requests per second or
    minute; there's a speedup if those requests don't require
    online validation.  Moving validations from multiple per second
    to once per five minutes saves a huge amount of system
    load.It's an economic tradeoff between the costs of incorrectly
    giving access and the cost of performing validation for every
    access.
 
  prabaths - 52 minutes ago
  Well... yes - one way to do that is to have a way to propagate
  revocation events from the issuer to the up stream applications -
  and each upstream application, possibly at the gateway level or
  at an inceptor will check the incoming tokens against a revoked
  list of tokens. You may also check: http://openid.net/wg/risc/.
 
  zeveb - 26 minutes ago
  The standard way, I think, is to issue a short-lived self-
  validating ('stateless') token for access and a long-lived
  validation-required ('stateful') token for access-token renewal.
  The mobile app logs in once and uses the access token until it's
  about to expire; the remote app server doesn't need to perform an
  online validation since the access token is self-validating.
  When the access token is about to expire, the client requests a
  refreshed access token from the remote token server using the
  refresh token.In other words, there's not a long-lived self-
  validating JWT.  If for some reason that were required, you might
  rotate the shared secret or signing key.
 
ejcx - 2 hours ago
If you're using microservices and care about security, do yourself
a favor and use a monorepo.A lot of improving security is about
changing things in small ways but across the entire fleet. If you
have microservices without a monorepo you oftentimes need to make
the same changes in potentially hundreds of places.This makes it a
lot easier to do things like enforce standards for repos. Code
coverage. Testing. Unsafe function use. Repo sprawl makes
microservice security very challenging, and it isn't mentioned in
this blog post. Losing track of services and leaving specific
services behind is not good.
 
  corpMaverick - 1 hours ago
  yes, yes, a thousand times yes.We implemented our services like
  this a few years back. It worked really nice. But in everything
  that I have read I have never seen any references to this
  practice. I didn't even know it was called "monorepo". I was just
  assuming everybody was using multiple repos and we were weird.
 
    Tushon - 1 hours ago
    Google and Facebook are the largest examples of monorepos that
    I'm aware of. Here is a write-up about it overall, though you
    don't need to be convinced :)https://danluu.com/monorepo/
 
      bluejekyll - 56 minutes ago
      Both Google and Facebook are also dealing with such large
      repos that they've needed to start either customizing or
      building their own SCM's. MS started the GitVFS project to do
      a similar thing to suit their needs.Most people aren't at
      that scale, but IMO, many benefits people get from monorepos
      you also get by using GitHub/Gitlab with master projects
      mapping in git repos via sub-modules.Anyway, it really sucks
      to work on extremely large monorepos when you don't have
      access to the same resources as Google and Facebook. For this
      reason I'm personally always hesitant to recommend monorepos
      as the be-all-end-all.
 
darethas - 2 hours ago
I was a little disappointed with the Newman book because arguably
the hardest thing to get right with a microservices system is what
to do when things go wrong, when things fail, specifically partial
failures. I also don't remember much about security in the book, so
I am thankful for this article.