Live data from Hacker News

Approaching Access Control on the Web (Part I)

ory.sh

31–40 of 41 posts

Re: Approaching Access Control on the Web (Part I)

#31
post #25

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.

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.

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

Re: Approaching Access Control on the Web (Part I)

#32

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.

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.

Re: Approaching Access Control on the Web (Part I)

#33

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.

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.

Re: Approaching Access Control on the Web (Part I)

#36
post #18

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 * Serv…

> * 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 actu…

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

That was it, amazing... thanks for your help

Re: Approaching Access Control on the Web (Part I)

#37
post #18

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 * Serv…

"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 authoriza…

Thanks for shedding more light on this.

Re: Approaching Access Control on the Web (Part I)

#38
post #19

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…

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/

Here is one cautionary tale showing why you would not want to use Macaroons:

https://about.sourcegraph.com/go/gophercon-2018-an-over-engi...

Re: Approaching Access Control on the Web (Part I)

#39
JWT with a split cookie seems brilliant to me. Good write up here: https://medium.com/lightrail/getting-token-authentication-ri...

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

Re: Approaching Access Control on the Web (Part I)

#40

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…

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.
Post reply on HN