Approaching Access Control on the Web (Part I)

> * There are a handful of typos scattered through the text, about 5-10 errors

Should be fixed now!

> Can you give an example on this?

An anonymous user is not authenticated but may still access some data.

> * Server-Side Distributed Applications, I don't have a solid conviction but I can't really see how multiple systems with multiple parallell accounts is a common, viable or even realistic situation...

This is actually not that unusual. Mostly happens when a company buys or uses a third-party CRM / SaaS or whatever!

"Authorization" answers "does the entity have permission to access the requested resource?"

"Authentication" is "is the entity is who it says it is?"

"Entity logging in" is an example of authentication. Is the entity trying to log in the entity it claims to be? An example claimed identity is a username, and example proof of authentic claim is a correct password.

"Entity trying to read data" is an example of authorization. Does the entity trying to read the data have permission to read that data? Checking an access control list against a username is an example of checking authorization.

How are they different, and separate?

I claim to be a user and supply a password. My claim is authenticated and I successfully log in. I have requested access to zero resources and thus no authorization has occurred.

A hacker steals my session while I'm logged in and requests my sensitive data. The system sees the request came from a username that is on the access control list for the resource and authorizes the hacker to see my data. No check on my actual identity (authentication) occurred, only a check whether the provided identity is authorized.

This is actually super useful.

What made you guys just decide to give out this? What's in it for you I mean?

At the BBC we use mutual TLS extensively in our cloud-deployed applications, across a lot of developers and different teams, for both service-to-service and developer-to-service auth (all devs get a client cert).

It works well for a lot of use cases, not least because most things are doing a TLS handshake anyway when communicating. That means that adding client certs into the mix isn't much of an overhead and you can avoid another authentication/authorization step if your CA hierarchy is well managed and you can trust that a cert which says "Joe Bloggs" is actually Joe's cert. Also obviously it avoids any 3rd parties, like you said!

That said, it only really works for us because a lot of apps are deployed through a centralised tool which adds relatively short-lived certificates to deployments and then automatically redeploys things before their certs expire. That ensures that certs stay valid. We also have a solution to handle revocation in the event that a cert is compromised, which is a massive pain.

So if you spend the time to set everything up it's pretty great, but the cost of setting it up is quite high. You'll also run into problems where you want to use some tool X but it doesn't support mutual TLS and you're forced to either find a different tool or hack in support if that's an option.

A big example of missing support is things like the Application Load Balancer in AWS (or equivalents in other clouds) - they tend not to support mutual auth, which means that you can't really use them and you're forced to use a more traditional load balancer with TLS passthrough and then terminate TLS somewhere else.

Because they have a lot of complexity that, for a code they runs a part of auth logic, is really dangerous.

For example, verification of third party Macaroons requires building a directed graph, that needs cycle detection. No implementation that I've checked does this instead allowing only one level of nesting.

Third party caveats have more problems, if a third party would issue them they need to be standardized but there is no such standard. Worse, even the underlying byte format is not standardized instead there is this de facto standard of using "variable op value" format. But what variables are supported? It needs to be specified or the third party macaroon would be invalid.

If we talk about byte formats Macaroons are serialized using another custom format. Compare this with base64 and JSON used by JWT.

Then there are certain "programming shortcuts" in implementations [0].

I've spent some time implementing Javascript library to build and verify Macaroons from the paper (that is also inconsistent with the de facto implementations) but ultimately I've decided to just use limited subset of JWT. It's just simpler.

[0]: https://github.com/nitram509/macaroons.js/blob/master/lib/Cr...