Approaching Access Control on the Web (Part I)

This looks great! Thanks for putting it together.

(Not convinced about "ultimative" though. I'm assuming you were going for a portmanteau of "ultimate" and "definitive", but I suspect a lot of people are just going to read it as "ultimate" and subsequently remember/Google the wrong thing.)

Nice :)

The first code example is missing an end ' in the endpoint string. '/some-protected-resource -> '/some-protected-resource'.

Have you looked into using Macaroons[1] at all for distributed systems? I used them for a client's multi-site intranet a while back, and it made some of the very complicated parts very simple. I'm just wondering why they never seem to have caught on.

[1] http://hackingdistributed.com/2014/05/21/my-first-macaroon/

Hey thanks for posting! Small request: Would you mind adding a date to your blog post? I'm sure visitors from the future will find it helpful.

I did use client side certificates for a while. It's a real pain to get the certificate installed, as it is different per OS and browser.

And I wouldn't call it 'really secure', I'd say it's just as secure as any other client side secret.

Webauthn is coming to browsers. It has a much easier UI than traditional client certs.

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.

I think there was a standard to generate keys in the browser, etc, but it got deprecated. The problem with certificates is moving them between devices. There are so many formats.

I've used client certificate authentication before, and two big problems present themselves. The first is the opacity of the error messages - if something goes wrong, you usually get a message like "SSL Error #128" with no further information to be found, even if you're reading log files on the server side, because TLS is implemented by low-level libraries. That could be solved with better library support, but the TLS standard (at least until TLS 1.2) makes it difficult to include detailed error information - sometimes for good reason, since too much info can itself be a security hole! The second problem I always run into is that certificates expire with no warning and no option to "ignore this error until I get a chance to fix it". Of course you and I can understand why this happens, but users generally don't.

> * 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.

Hey! That's a great point. John (our designer) is currently on vacation but he will create some animated SVGs which make this easier to digest!

We were also thinking to have an interactive "decision map" where you start with what type of application you develop (e.g. prototype, distributed app, ...) and step-by-step come closer to a recommendation from us. We might also include some software in the last step to guide you to the right pieces. Would that be something you'd like to see?

Never :) No affiliation with Palantir!

Use a monkeyscript to set by yourself ?