Here's where I've gotten with custom user authentication, this may be a
starting point for some
people: https://gist.github.com/pciet/8529531fffbe8d9523d883c901d311da
Matt
On Thursday, January 25, 2018 at 4:40:29 PM UTC-6, Jeff Goldberg wrote:
>
> On Jan 25, 2018, at 2:58 PM, Pat Farrell <pat2...@gmail.com <javascript:>>
> wrote:
>
> > On Thursday, January 25, 2018 at 8:33:40 AM UTC-5, matthe...@gmail.com
> wrote:
> > > (2) would using a session cookie + some authorization middleware
> (such as casbin) make sense for our situation? what are its pro's and
> con's?
> >
> > In a pure micro-services architecture, you have to check every request
> in every micro-service, its the nature of the beast. Of course, you pass
> around a local token that expires in a 'short' time.
>
> What I am going to describe here is overkill for almost everyone, and
> certainly for a "first time building”, but it gives me the opportunity to
> discuss another way of managing authenticated sessions with a RESTful API.
> Note, however, that it requires specific client code.
>
> With 1Password.{com,ca,eu}, we maintain an “authenticated session” that is
> referenced by the client through a non-secret SessionID. (It could be a
> non-secret cookie, but we put it in the URI). When the client first
> authenticates, it does so using (a slightly non-standard version of) Secure
> Remote Password, SRP:
>
> https://godoc.org/github.com/agilebits/srp
>
> this establishes a session key, which both the client and server will
> know. (It does this without exchanging any secrets.)
>
> After that, all requests are authenticated and encrypted with the session
> key (or a key derived from the session key). This is all on top of TLS,
> which we do not entirely trust. Thus, every client request contains a proof
> that it knows the session key without ever transmitting it.
>
> > Wiring your own that mostly works is trivial. Getting all the tiny
> details is very pedantic, and its easy to get wrong. Which is why its
> critical to ask how serious you are about value and potential attackers
>
>
> Again, what we do is going to be overkill for most setups. And it was a
> lot of work to build. But our security needs are probably different than
> most people’s. Our authenticated session management isn’t as cleanly
> module-erized as the SRP code, so we aren’t ready to publish that, but its
> on our wishlist of stuff we would someday like to publish.
>
> Cheers,
>
> -j
>
> –-
> Jeffrey Goldberg
> Chief Defender Against the Dark Arts @ AgileBits
> https://1password.com
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
