Hacker News new | past | comments | ask | show | jobs | submit login

I don't actually believe JWT is useful for that, and indeed recommend something simpler like OAUTH2 (OpenID Connect) simply because it actually handles this use-case, and because it doesn't require any cryptography or anything complicated for a (junior) developer to consume correctly.

EDIT: I just saw your spreadsheet. Perhaps you have gotten a bad impression of OAUTH2 by looking at some client libraries. Many of these are made complicated by trying to handle all aspects of OUATH2 instead of the single-sign-on flow, which is simple enough you shouldn't even need a library[1].

[1]: https://aaronparecki.com/oauth-2-simplified/




OpenID Connect is based on JWT: http://openid.net/specs/openid-connect-core-1_0.html#IDToken

If JWT is too complicated and confusing, OpenID Connect inherits all that complexity and then adds some more.


OAUTH2+OpenID Connect does not require a consumer or producer read, parse, or produce a JWT for the single-sign-on flow.

The authentication event is a regular JSON object.

There is no need to validate it since it was received from a server-to-server TLS-protected HTTPS request.

This is not anywhere near as complicated as using JWT for session storage directly.


Well, if you're using authorization code flow, trust your TLS certification authorities enough, then yeah, it's probably safe, though you'll be definitely violating the spec: http://openid.net/specs/openid-connect-core-1_0.html#CodeFlo...

But if you go as far as not verifying the ID Token for, what do you need OpenID Connect for? Just use plain old OAuth 2.0.


There are a lot of convenient things to lift out of OpenID Connect, for example:

* The Discovery URL

* Standardisation in the subject name

* The userinfo endpoint


Sort of agree that the example I provided isn't the best use case for JWT. Perhaps a better example is email verification - you send a link in the email with a JWT.

re. OAuth2 - I wrote the spreadsheet from the point of view of a developer of REST APIs. As a developer exposing APIs, OAuth2 is only useful if I want my users to decide what data they want to share with third party developers.


> Sort of agree that the example I provided isn't the best use case for JWT. Perhaps a better example is email verification - you send a link in the email with a JWT.

Have you seen how Steam performs email verification as part of a 2FA successful login flow?

For password-recovery flows, you may still want to log (audit) attempted password recovery, which means a database hit anyway. From that perspective, "magic link" is good enough.

> OAuth2 is only useful if I want my users to decide what data they want to share with third party developers.

When you have logged in with an OAUTH2 provider, you're given a token which can be used against the API in any of the mechanisms you describe if your users are likely to do more than one request. Even if you only ever authenticate over your own OAUTH2 provider, this might still have advantages involving audit, reliability/availability, and so on.

One thing that I find very useful is using OAUTH2 to hand over authentication to my customers; they want to have their own password policy, and their own two-factor system, and so on. I don't want to implement that for every customer. Even when I implement a OAUTH2 provider for each customer I can do this easily, but nowadays, they might be able to use Amazon Cognito, or Azure to log into my API.

The first time someone wants to consume my REST API from within their dashboard, I'm already ready for this: I can build an SSO between their dashboard and my OAUTH2 provider (or just use theirs!) keeping everything separate from my actual business API, and the customer feels like this was a massive customization.

And so on.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: