
Approaching Access Control on the Web (Part I) - malachygr
https://www.ory.sh/api-security-cloud-guide-overview.html
======
malachygr
Hi there! From experience we know how hard auth* systems can be. There are a
million ways to get what you want. We also see the issue that developers
usually start with a least-effort approach (username + password) which needs
refactoring later on. The intention of these articles is to give you an
overview of what exists and help you choose the best approach with as much
information as you can get. We hope that this saves you some time. If you
haven't heard from us before, I welcome you to check out our open source
products which are all related to auth*:
[https://github.com/ory](https://github.com/ory)

We will plug some of these (and other) open source products in the articles,
but we really want to teach you something. There is so much SEO-optimized
onboarding (for expensive blackbox SaaS) content with little substance on this
topic. We really hope this helps you!

One last thing: We hope it's ok that the other parts are not ready yet. Aeneas
(author of the guide) is trying to push out one ~ every month! Getting this
content right is a lot of work :)

Cheers!

~~~
cmpb
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/](http://hackingdistributed.com/2014/05/21/my-first-macaroon/)

~~~
Boulth
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...](https://github.com/nitram509/macaroons.js/blob/master/lib/CryptoTools.js#L51)

------
deckar01
I recently found out about TLS client authentication via client certificates.
It seems like a really secure mechanism for authentication that just doesn't
have a standardized UX/API for initial cert exchanging and multiple device
registration. I am hesitant to rely on a 3rd party SSO provider to remain
available. I would much rather rely on a decentralized technology like the TLS
certificate network.

~~~
LeonM
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.

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

Only if you store the cert in a file, but you can store it on a smartcard
(e.g. Yubikey) or a TPM.

------
aliswe
Really nice.

> But authorization does not require authentication, and neither does
> authentication require authorization.

Can you give an example on this?

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

* As I was into learning mode, in the middle of the article I didn't initially notice that the server product you recommending was your own. I think a clarification there is in place

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

~~~
TravelAndFood
"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.

~~~
aliswe
Thanks for shedding more light on this.

------
jordache
you missed a main point in your opening paragraph. Security is best not
implemented as a custom solution. There are so many things to get wrong and if
you do get even a single detail wrong, it could break the entire
implementation.

------
mathnmusic
At the very least, webapps should abstract out registration and login
processes into a middleware, instead of building their own. This will make it
possible to trivially implement single-sign on and sharing auth infra across
various tools - especially open-source.

------
dstroot
JWT with a split cookie seems brilliant to me. Good write up here:
[https://medium.com/lightrail/getting-token-authentication-
ri...](https://medium.com/lightrail/getting-token-authentication-right-in-a-
stateless-single-page-application-57d0c6474e3)

By splitting the JWT across two cookies, rather than using a single cookie or
having the JWT stored in the browser local storage, we are able to meet our
requirements...

------
da_murvel
Nice! I've been looking for something like this for ages. If I could make a
wish, I'd love to see some sort of interactive stuff, or at least
visualisations of for example username/password -> cookie exchange. To make it
easier to digest. Not everyone prefer to learn by reading :)

~~~
malachygr
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?

~~~
retendo
That would be great :)

------
rdli
Ory's great, and glad to see they're integrating more with other technologies,
e.g., [https://www.ory.sh/api-access-control-kubernetes-cloud-
nativ...](https://www.ory.sh/api-access-control-kubernetes-cloud-native/).

------
eganist
OP: Hi! Anyone ever tell you your logo looks strikingly similar to Palantir's?

It was enough to make me wonder if Ory is a Palantir offshoot, which doesn't
appear to be the case.

~~~
malachygr
Never :) No affiliation with Palantir!

~~~
eganist
Well, I suppose I'm the first.

If I can inquire further: are you open to discussing ORY's revenue model? I
love organizationally-backed open source projects pertaining to security as
there's a less than savory trend in this space for tools to go unsupported
after original maintainers have moved on, but I have a bad habit of loving
them less when I can't quite nail the business model of the primary entity
supporting the projects. I see consulting is likely some part of it, and my
guess is there's a product ORY is working on which will monetize an extension
of either/both Hydra and Oathkeeper in the future, but hopefully you can see
why I'm asking for a more definitive clarification and are in a position to
shed some light.

~~~
malachygr
Hi, mostly consulting, sponsorship and paid additions to the open source
ecosystem. In the future we'll offer managed cloud services. We're not doing
open core though, if that's what you're getting at :)

~~~
eganist
Sponsorship, e.g. Patreon?
[https://www.patreon.com/_ory](https://www.patreon.com/_ory)

Thanks for the insight!

~~~
malachygr
Yes, but we're also moving to open collective for this. Patreon is more for
individuals while open collective is for open source collectives.

------
ArkaneSkye
This is actually super useful.

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

------
cfj
This looks great. Looking forward to the coming parts.

------
roadbeats
Recommendation for the owner of the site: The line-height is set too high. It
should be max. 1.7

~~~
revskill
Use a monkeyscript to set by yourself ?

