Hacker News Reader

Comment by JoshMandel | Hacker News Reader

1. To my mind, the fundamental problem OAuth solves is "letting a user decide" to share data with an app, without making the user responsible for jumping back and forth between the app and her API provider (her bank, in this case). OAuth holds the user's hand through a series of redirects, and the user doesn't have to copy/paste tokens, or remember where she is in the flow, or know what comes next. Does TAuth have a similar capability? The blog post mentions "User Tokens" in passing, but doesn't define or describe them.

2. OAuth 2.0 is published as an RFC from IETF. It may be a bear to read (and yes, it's a framework rather than a protocol!), but the spec is open, easy to find, and carefully edited (https://tools.ietf.org/html/rfc6749). Is TAuth meant as a specification, or a one-off API design? If it's a specification, has there been an attempt to write it down as such?

View on HN

On 2: from the OP, "TAuth is available in production today for our existing beta users and we've already begun the work to make it an open standard we hope the industry adopts."

I disagree with your first point. The fundamental problem OAuth solves is secure authentication. OAuth 2.0 provides this at a bear minimum as it can be broken in any way SSL/TLS can be broken.

The argument the author is making is that this level of security is not sufficient for a bank. I think I agree with this statement.

For general use, OAuth 2 provides a sufficient level of security since the platforms that use it are usually only as secure as TLS, too.

Nope, authorization. Authentication is left as an exercise for the implementer.

Some people use the ability to be authorized to access an account on e.g. Facebook as a stand-in for authentication, but that's a different issue.

Is that not a fair thing to do?

Can we not assume someone with access to a Facebook account is authentically the owner of that Facebook account for all of our intents and purposes?

Authentication is to prove who you are - authorization is to just have permission to do something, as a subset of authenticated rights.

You would generally be much less rigorous in the Facebook example between giving someone access to your shared photo albums than to your account settings. Having an oauth token does not make you signed into Facebook at all, but just says that you have valid rights to do something.

As it is right now, yes. But imagine a scenario where Facebook might implement a child account where a parent has access to monitor the usage.

Now there are two people with authorisation to access this Facebook account so the process no longer unique authenticates a single individual.

Of course this is a contrived example and I'm sure there are better examples. But this is why OAuth is authorisation and not authentication and why something like OpenID Connect exists on top of OAuth2.

Reply on news.ycombinator.com