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
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 :)
(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.)
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.
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.
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 :)
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?
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.
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 :)
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.
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.
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.
> 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...
> * 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.
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.
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...
40 comments
[ 400 ms ] story [ 1818 ms ] threadWe 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!
(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.)
The first code example is missing an end ' in the endpoint string. '/some-protected-resource -> '/some-protected-resource'.
[1] http://hackingdistributed.com/2014/05/21/my-first-macaroon/
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://about.sourcegraph.com/go/gophercon-2018-an-over-engi...
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?
It was enough to make me wonder if Ory is a Palantir offshoot, which doesn't appear to be the case.
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.
Thanks for the insight!
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.
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.
> 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...
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!
That was it, amazing... thanks for your help
"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.
What made you guys just decide to give out this? What's in it for you I mean?
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...