Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Child’s Garden of Inter-Service Authentication Schemes

latacora.singles

Post reply on HN
Print view View original

21–30 of 54 posts

Re: A Child’s Garden of Inter-Service Authentication Schemes

#21

Post by pvg »

tptacek wrote: post #14
jameshart wrote: post #10

Earlier quoted context omitted.

Apologies for misattribution :) So yes, this is precisely the problem with sending the message 'JWT is bad' when what you really want to send is 'bearer tokens are bad (and JWT is a badly designed bearer token)'. I am reminded of the situation a few years ago where the message 'stop hashing/salting passwords with SHA1' got widely interpreted as 'Okay, I'll salt and hash with SHA256', when the real message that was ne…

That argument doesn't work, because JWT isn't just a "bearer token". It's also potentially an asymmetric token, or any other mechanism someone tries to shoehorn into it next week. That's one of the problems with metaformats. This post isn't a comprehensive argument against JWTs and isn't intended to be. We can't have the conversation about JWT in earnest until we understand the problem domain.

We can't have the conversation about JWT in earnest until we understand the problem domain.

That you're taking it from there is really interesting. Are you finding a lot of JWT use when there's also some S2S auth setup?

Re: A Child’s Garden of Inter-Service Authentication Schemes

#22

Post by shkkmo »

tptacek wrote: post #19
shkkmo wrote: post #18

Earlier quoted context omitted.

Our partners are not commercial SSO systems, nor do they all use commercial SSO systems. We looked at SAML and it didn't seem to be a good fit for our use case. It is overly complex for our needs. Instead we built a very small subset of what SAML allows, that is very easy to understand and allows our partners to use lightweight JWT libraries with simple APIs instead of trying to figure out how to get a complex SAML i…

The model that you described is, verbatim, the bearer model of SAML that everybody uses. SAML in theory does more than just that, but the flow you just described is the subset of SAML that every open source SAML library implements. Apart from some minor security controls that you didn't describe and that SAML implements, the only difference is that you built your ad hoc system using JWE, and SAML is built with XMLDSI…

> I can only assume that the most widely-used flow in SAML, the dominant SSO protocol on the Internet, is better documented than the ad-hoc custom version of SAML you reimplemented with JWT. :)

JWT has much better documentation than anything I was able to find on SAML, but this may be due to my lack of experience with the domain. I had trouble even finding clear documentation on what the basic structure of a SAML assertion should be. As a developer with limited knowledge of the domain, when picking a tool to solve my problem I default to the simpler tool with more accessible documentation.

The documentation for utilizing our JWT implementation is simpler and more straightforward than what Salesforce provides for it's similar flow implemented with SAML.

> the problems I have with SAML are all shared by JWE/JWT!

And what are those? This was my original question.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#24

Post by sytringy05 »

pvg wrote: post #21
tptacek wrote: post #14

Earlier quoted context omitted.

That argument doesn't work, because JWT isn't just a "bearer token". It's also potentially an asymmetric token, or any other mechanism someone tries to shoehorn into it next week. That's one of the problems with metaformats. This post isn't a comprehensive argument against JWTs and isn't intended to be. We can't have the conversation about JWT in earnest until we understand the problem domain.

We can't have the conversation about JWT in earnest until we understand the problem domain. That you're taking it from there is really interesting. Are you finding a lot of JWT use when there's also some S2S auth setup?

Everybody is doing it (at least where I'm from). There's good framework/vendor support for OAuth 2 and JWT breaks the nexus between the services and the magic auth server that must be called on each and every request.

Even with the horrors of the implementation ({"alg": "none"}) It's a risk that many organisations are willing to take.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#25

Post by ithkuil »

dward wrote: post #15
jameshart wrote: post #4

Is this finally the more expansive statement from tptacek than just "Don't use JWTs" that I've been waiting for? Still feels like we're waiting for another shoe to drop in this space - maybe it really is Macaroons? But since container-driven microservice orchestration is ultimately destined to recapitulate the whole of CORBA and DCOM and therefore probably kerberos and every flavor of PKI ever attempted before it get…

The published asymmetric macaroon constructions were pretty gross last time I looked. We were missing a practical asymmetrically verifiable append only signature. This deficiency rules macaroons out of numerous use cases (namely where the relying party is separate from and untrusted by the issuing party).

I found this part to be one of the most common gotchas of macaroons. As often happens when everybody is "holding it wrong", users are not probably the only ones to be blamed.

That said, macaroons (from what I understood) are meant to be a token that is only verifiable by the issuer.

Third party caveats allow more complex scenarios, but they necessarily involve actual s2s communication to set up (as opposed to the "verification at a distance" allowed by pure asymmetrical crypto)

For example: service A issues a macaroon to service B. Now imagine service B needs to talk to service C, which in turns needs to ensure that B can perform some action on service A. If C could verify A's public key signature, we could stop here.

With macaroons, C needs to issue a macaroon to B, with a third party caveats that requires B to obtain a "discharge macaroon" from A. When B later performs the request on C, it brings both macaroons (the one issued by C with the 3rd party caveat, and the one issued by A, that proves that the caveat is discharged).

C can verify such a macaroon. In particular it can cheaply verify that A is the source of the 3rd party verification.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#26

Post by pvg »

sytringy05 wrote: post #24
pvg wrote: post #21

Earlier quoted context omitted.

We can't have the conversation about JWT in earnest until we understand the problem domain. That you're taking it from there is really interesting. Are you finding a lot of JWT use when there's also some S2S auth setup?

Everybody is doing it (at least where I'm from). There's good framework/vendor support for OAuth 2 and JWT breaks the nexus between the services and the magic auth server that must be called on each and every request. Even with the horrors of the implementation ({"alg": "none"}) It's a risk that many organisations are willing to take.

Right, but it sounds (if I'm understanding you right) like you're talking about JWT-and-things-as-a-way-for-your-services-to-talk-to-each-other-through-the-client. This is roughly analogous to Ruby cookies - save yourself a database read through the power of maths.

But tptacek seems to be saying 'I want you to understand all this S2S stuff before I can begin to rant at you about JWT'. That's a bit different and I'd like to get the rest of this newsletter.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#27

Post by sytringy05 »

pvg wrote: post #26
sytringy05 wrote: post #24

Earlier quoted context omitted.

Everybody is doing it (at least where I'm from). There's good framework/vendor support for OAuth 2 and JWT breaks the nexus between the services and the magic auth server that must be called on each and every request. Even with the horrors of the implementation ({"alg": "none"}) It's a risk that many organisations are willing to take.

Right, but it sounds (if I'm understanding you right) like you're talking about JWT-and-things-as-a-way-for-your-services-to-talk-to-each-other-through-the-client. This is roughly analogous to Ruby cookies - save yourself a database read through the power of maths. But tptacek seems to be saying 'I want you to understand all this S2S stuff before I can begin to rant at you about JWT'. That's a bit different and I'd l…

No, I meant in the context of server to server comms, as well as end user authn/authz.

I would say that jwt is becoming the standard for s2s. I’ve personally worked with a dozen or so corporate APIs that use it and basically all the Microsoft Azure / 365 services are secured with jwt.

I’m intrigued by macaroon because as tptacek points out JWT is easy to get wrong, you’ve got to deserialize json before you can authenticate the request and it’s also tempting to stuff all manner of things into the token claims.

Re: A Child’s Garden of Inter-Service Authentication Schemes

#28

Post by jessaustin »

sarcasmic wrote: post #11

If you're like me and are wondering what Macaroons are, some searching revealed to me that this is the 2014 paper [1] that introduced them to the public. It's a nested, chained HMAC construction that's useful for delegation, and here's a library and some code examples [2] that one can play with to get a feel for what they do and how. No wonder it's not well known: it hasn't been picked up by the blog treadmill where…

These libs seem to have seen more recent maintenance:

https://github.com/go-macaroon

Re: A Child’s Garden of Inter-Service Authentication Schemes

#30

Post by bullen »

jameshart wrote: post #29
bullen wrote: post #23

I just use hashing with single use server salt, why is that not mentioned here. It's secure and simpler than everything else.

Hashing or HMACing? How is ‘single use’ of the salt enforced?

Just hash = hash(secret + salt) and the server enforces the single use by generating and sending one for each authentication, so you need double handshake:

client ----- server

req salt -> gen salt

hash sec. send hash -> remove salt

all good? <- verify hash

Post reply on HN