Hacker News Reader

Comment by mgaunard | Hacker News Reader

As a non-web person, I find everything related to this auth business needlessly complicated and arbitrarily limited. Most of the time it's not even implemented correctly anyway (many application not checking the JWT audience...) because web devs just use libraries without understand what actually provides the security.

As an application writer, I want the user to feed me a token signed by a trusted entity that proves he is who he claims he is and has the necessary accesses enabled for my application.

Whether this happens transparently via a redirect to the trusted entity login webpage and back to my app or whether I request the user to go to a specific url on their own while I wait for them to do so is just an UX detail. Why every approach needs to be labeled a "flow", authorized separately, and come with their own limitations is beyond me.

View on HN

Because web browsers are a massive hack and nothing works 100% so theres 10 different flows to cover which sort of broken is acceptable to your use case.

> Whether this happens transparently via a redirect to the trusted entity login webpage and back to my app or whether I request the user to go to a specific url on their own while I wait for them to do so is just an UX detail. Why every approach needs to be labeled a "flow", authorized separately, and come with their own limitations is beyond me.

The reason they're called flows is because they each compose one or more single steps from the OAuth2 "toolbox" (i.e. endpoints). Many flows will have overlapping or even identical "steps", but the order of things matter and the modes in which they interact matter, which is why the second layer of delineation is necessary (or useful, at least).

because web server, browser and protocol developers, after implementing HTTP Basic Auth punted and said this is gross and hard. They then gave up on the problem.

The problem still existed, and other developers took a stab, but they weren't protocol or cryptography people, so we got a bunch of mostly broken stuff. Some cryptographers came along and pointed out the disasters, and since then it's been slowly getting better, but it's still a giant mess.

Companies have decided, since we have to solve it for us, we can just solve it for you too, and now we have "social logins" where we tell Microsoft, Apple or Google everything we login to. They appreciate the extra information to help themselves, so it's a worthwhile incentive for them.

The web browser developers got a little involved with passkeys, but the UX is still not idiot proof. Better than their last two tries at implementing public key auth though(TLS client certs and DOD auth).

>i want the user to do this very particular thing in an absolutely correct way

good luck

> As a non-web person,

Yes, indeed.

> I find everything related to this auth business needlessly complicated and arbitrarily limited.

You find a subject you do no understand or were bothered to learn about to be needlessly complicated and arbitrarily limited?

> Most of the time it's not even implemented correctly anyway (many application not checking the JWT audience...) because web devs (...)

You seem to be very opinionated over things you clearly know nothing about.

Among the many ways you manifested your cluelessness, OAuth is not a "web dev" thing. It's a "software communicating over a network" thing. Desktop apps must support it, so do mobile apps, and web services need to support it both as client apps and resource services.

Also, to drive home your clueless ignorance, "checking the JWT audience" is not a authentication thing, which is the responsibility of OAuth. The full name of OAuth2 is "OAuth 2.0 Authorization Framework". It covers delegating authorization to third parties so that clients can access a user's claims. Claims are not authorization either.

In the end you were awfully critical of something you don't even know what is?

> (...) just use libraries without understand what actually provides the security.

I think you should take a step back and meditate over your post. It says nothing about OAuth, and everything about how little understanding you have over OAuth and how vocal you are on a topic you know next to nothing.

I've implemented those components from scratch in C++ to provide single-sign-on authentication across a variety of distributed sensitive applications, without using any libraries, so I'd say I'm fairly familiar with how they actually work.

JWT is by far the most important building block here, and while it's not part of OAuth, realistically it's how anyone sane would use OAuth.

> JWT is by far the most important building block here, and while it's not part of OAuth, realistically it's how anyone sane would use OAuth.

There's a degree of confusion in your comment. I pointed out the fact that OAuth handles authentication, not authorization. Those who fail to understand this clearly don't know the basics of the whole system. This is what I posted in my previous reply to your post.

The same applies to JWTs. They are the output of an authentication process. They do not authorize anything. They bundle a set of claims along with metadata used to prove they can be trusted and when they are valid. They are designed in a way that resource servers can validate them locally before actually handling any authorization concern.

The authorization part is handled by the systems which check these claims. It's a separate concern, handled separately by separate systems. If you were familiar with any OAuth flow, you'd be aware that this part takes place only after any of the flows take place, and is way outside of their scope.

This is what I'm talking about. If you do not understand the problem domain then you are in no position to criticize or complain about how solutions are implemented. You can only complain about the time you're wasting criticizing things you know nothing about.

Authorization is derived from authentication; authentication is the core concept underpinning security, while authorization is about defining the scope of the access.

Restricting the scope is mostly useful for when you need to interact with services that talk to other underlying services without granting them full access to those, but in practice, that's not a very common case outside of the web.

Ultimately that distinction doesn't really matter, what's important at the end of the day is how you implement the access control. Using an opaque token and an introspection endpoint is a terrible idea. JWT is a good solution. All of the OAuth flows do is just provide convoluted ways for the user to authenticate with a identity provider, generating a JWT on his behalf, and do not contribute to security in any meaningful way.

JWT doesn't support revocation, which is a pretty fundamental flaw.

Tokens typically expire after 8 hours at most.

Why are you so condescending?

It's always very jarring to come across a post that is so drastically different in tone when you're just trying to follow a comment thread.

> I think you should take a step back and meditate over your post.

I wish you'd follow your own advice.

> Why are you so condescending?

It's not condescending. You're faced with a highly critical comment criticizing a whole framework when clearly the critic is completely oblivious to the most basic aspects of the whole domain. They know nothing about the whole problem domain, even failing to understand the most basic aspect of what they are doing or what they hope to achieve, but they still invest a lot of energy generating noise that's firmly in the "not even wrong" region. This serves anyone no good.

Reply on news.ycombinator.com