Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What do you use for authentication and authorization?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 247 posts

Re: Ask HN: What do you use for authentication and authorization?

#51

Post by throwawaymath »

geezerjay wrote: post #45
throwawaymath wrote: post #39

Earlier quoted context omitted.

No, it's not false. Tutorial "best practice" guidance does not constitute a standard. JWT does not provide native revocation. Neither refreshes nor expiry constitute revocation. Revocation is an active state change, not a dead man's switch.

Yes, that's patently false. The exp payload field is even specified in JWT's RFC along with the token rejection workflow. https://tools.ietf.org/html/rfc7519 The same document also specifies the jti field which is the JWT's nonce.

Again, expiry is not revocation. This is an uncontroversial fact - if you disagree, please advise me as to how you'd revoke a token prior to its timestamp-mandated expiration without augmenting it further.

And the jti field is not intended for what you think it is. Anti-replay is not at all the same as revocation. Those are different things entirely.

I certainly believe (and have seen) the jti field used in the manner you describe. But no, that workflow is not intended for revocation. Which makes sense given the design intentions of JWT, because anti-replay can be accomplished as a stateless process, while revocation cannot.

Re: Ask HN: What do you use for authentication and authorization?

#52

Post by cbo100 »

geezerjay wrote: post #47
cbo100 wrote: post #46

Earlier quoted context omitted.

In what way? You simply get a bearer token (non JWT) onto the client and use that from local storage instead of a cookie. Your JavaScript code then makes api calls using the same bearer pathway as other api clients. The token can still expire, be revoked, etc. it just prevents you having to handle cookie auth on your api.

You've just described the JWT workflow.

Which is fine to use the same logic, as it’s a robust, easy to understand system. but if you aren’t using JWT then you aren’t using JWT.

The parent comment saying “that sounds like JWT” is implying it’s just as bad or has the same shortfalls as using JWT.

Re: Ask HN: What do you use for authentication and authorization?

#53

Post by geezerjay »

throwawaymath wrote: post #48
geezerjay wrote: post #40

Earlier quoted context omitted.

> No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. That's technically false. JWT features multiple systems of revocation, including the use of nonces. Token revocation also features prominently in JWT's basic workflow. The key aspect is that there is no turnkey implementation, and thus projects need to roll their own implemen…

By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. It naturally follows that no JWT implementation provides a turnkey solution for revocation, because it's not intended to. JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation sys…

> By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation.

That's patently false.

JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes.

The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens.

> JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control.

This sort of argument is ivory tower nitpicking stated disingenuously. JWT include issue and revocation timestamps, which already renders the workflow stateless. The only stateful aspect, which is silly nitpicking and technically irrelevant, is keeping track of nonces and arbitrarily revoked tokens, which require keeping a database to track revocations.

Re: Ask HN: What do you use for authentication and authorization?

#54

Post by moltar »

metafunctor wrote: post #36
arkadiyt wrote: post #4

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…

If you have an API, you can program your web client like an API client, using bearer tokens for authentication (put them in local storage). It's probably better than cookies.

How is that better than a cookie though? Cookies already provide automatic storage and expiry mechanism. Bonus feature is that they are not accessible by JS code at all, if set httponly flag.

Re: Ask HN: What do you use for authentication and authorization?

#55

Post by moltar »

geezerjay wrote: post #53
throwawaymath wrote: post #48

Earlier quoted context omitted.

By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. It naturally follows that no JWT implementation provides a turnkey solution for revocation, because it's not intended to. JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation sys…

> By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. That's patently false. JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes. The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens. > JWT…

If you have to track revoked tokens you might as well track active sessions via a session ID.

Re: Ask HN: What do you use for authentication and authorization?

#56

Post by geezerjay »

throwawaymath wrote: post #51
geezerjay wrote: post #45

Earlier quoted context omitted.

Yes, that's patently false. The exp payload field is even specified in JWT's RFC along with the token rejection workflow. https://tools.ietf.org/html/rfc7519 The same document also specifies the jti field which is the JWT's nonce.

Again, expiry is not revocation. This is an uncontroversial fact - if you disagree, please advise me as to how you'd revoke a token prior to its timestamp-mandated expiration without augmenting it further. And the jti field is not intended for what you think it is. Anti-replay is not at all the same as revocation. Those are different things entirely. I certainly believe (and have seen) the jti field used in the manne…

> Again, expiry is not revocation.

Issue and expiration timestamps are used along with nonces to enforce single use tokens. Once a token is used then the client is expected to discard and refresh the token.

Implementations are also free to keep track of issued tokens and that does not pose any problem in the real world.

> And the jti field is not intended for what you think it is. Anti-replay is not at all the same as revocation.

Why are you expecting to revoke a token in a scenario where the token is supposed to be used once?

Either the token is deemed valid and accepted or it's invalidated and rejected, which triggers clients to refresh the token and retry the request.

Re: Ask HN: What do you use for authentication and authorization?

#57

Post by InGodsName »

Once we lost the user account DB at a startup to database data loss and some other day, someone logged into mongodb and dropped all the tables and backups were not test before, so they did not work.

After that we no longer store these details.

We've been using amazon cognito with lambda authorizers.

Re: Ask HN: What do you use for authentication and authorization?

#58

Post by InGodsName »

aeleos wrote: post #8

I was in a similar position, we started using Okta and eventually migrated to AWS Cognito. Rolling your own auth is a recipe for disaster unless you know what you are doing and really need to. Also, be prepared to be fairly locked in once you choose an auth provider, especially if you choose one that is fairly integrated into your ecosystem.

We use Lambda authorizers, how do you use cognito

Re: Ask HN: What do you use for authentication and authorization?

#59

Post by INTPenis »

If your plan is to connect other services then I'd suggest using LDAP for central authentication.

It can easily be connected to any API without much "glue". And most common open source services already support it as auth backend.

It's also easier to audit than any custom service you might concoct on your own because auditors already have experience with it through Active Directory.

Re: Ask HN: What do you use for authentication and authorization?

#60

Post by weego »

moltar wrote: post #55
geezerjay wrote: post #53

Earlier quoted context omitted.

> By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. That's patently false. JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes. The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens. > JWT…

If you have to track revoked tokens you might as well track active sessions via a session ID.

That's just an argument ignoring the realities of scale. In any reasonable system the number of tokens that need to be held in blacklist until seen will be tiny in comparison to active sessions.
Post reply on HN