8 ms·
I maintain a spreadsheet of the pros and cons of various authentication techniques - https://docs.google.com/spreadsheets/d/1tAX5ZJzluilhoYKjra-uHbMCZraaQkqIHl3
by ksri 9y ago
I maintain a spreadsheet of the pros and cons of various authentication techniques - https://docs.google.com/spreadsheets/d/1tAX5ZJzluilhoYKjra-uHbMCZraaQkqIHl3RIQ8mVkM/edit#gid=0 https://docs.google.com/spreadsheets/d/1tAX5ZJzluilhoYKjra-u...
JWT is extremely useful when you want a one-time use token to pass a claim to another system. For example, employee portal generates a link for a user to check their available leaves in the HR system. Since the user is logged in to the employee portal, they shouldn't have to login to the HR system. JWT is great for this use case. But for general sessions management, there are better solutions.
- vetinari 9y agoThe use case you mention is exactly the reason, why we have SAML2 and similar SSOs.
- wichert 9y agoIt appears to be much, much simpler to just integrate JWT into your system than deploy a SAML identity provider. I would love to see an easy to deploy decent SML IdP, but so far I have not found one. If anyone has any recommendations I would love to hear them.
- brazzledazzle 9y agoIf you're looking for a self-hosted solution I can't help but as far as a provider goes we've had decent success with Okta. Of course SAML kind of sucks no matter how you slice it and Okta seems to think the future is in standards like openID connect.
- sytringy05 9y agoThey dont exist! IMHO ADFS is actually the best of a bad lot. Your friendly Windows Admin can setup the SSO in a matter of minutes without having to know the spec inside out and upside down. The other platforms I've used or integrated with - Tivoli, Layer 7, Ping Federate, a huge hack job written in PHP - all took weeks/months to get working. That said I haven't tried Spring SAML recently, so maybe that is painless now. But probably not
- thaeli 9y agoI've been happy with SimpleSAMLPhp in production for about 6 years now. Configuration was very straightforward and the whole process was order-of-magnitude simpler than any other SAML IdP we tried at the time.
- vetinari 9y agoKeycloak (http://www.keycloak.org/ http://www.keycloak.org/) is quite easy to deploy. For our usage, even that was overkill and we are using Ipsilon (https://ipsilon-project.org/ https://ipsilon-project.org/), with IPA backend. It is more quirky, docs are scarce, but it works for us. On app side, it is mod_auth_mellon.
- rb12345 9y agoShibboleth should cover the "decent" side of your question, given it's pretty heavily used in academia. The SP side of things is fairly straightforward to setup; whether the IdP counts as easy to deploy is probably a matter of opinion and experience.
- zxcmx 9y agoExcept if you use saml, now you have xml digital signatures. If you thought jwts were bad, take a look at the specs for xml digsig sometime. You can specify multiple signed portions of a document, have multiple sigs, or choose to sign only a part, use a bunch of different algorithms, specify your own canonicalization rules, and you get all the usual fun of xml parsing risks. If jwts are bad, xml digsigs are "literally cthulu".
- scandox 9y agoI was involved tangentially with a project where there was a SAML2 based federated login to be put in place and I remember there were 3 conference calls before the devs implementing it even understood the flow. I don't even think the guys on the other end understood it properly.
- NewEntryHN 9y agoGood work with the spreadsheet! It states about Stateful Session cookie that it's "supported by all web frameworks and browsers.", but Flask is an example of popular web framework which doesn't support them. The "session" in Flask actually uses Stateless Session cookies.
- ksri 9y agoYes, I went a little too far with "all web frameworks". I just changed it to "most web frameworks".
- xyz-x 9y agoSuave.io also uses stateless session cookies; storing all state in the cookie itself. Also, what about Hawk? https://github.com/hueniverse/hawk https://github.com/hueniverse/hawk
- geocar 9y agoI 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/ https://aaronparecki.com/oauth-2-simplified/
- unscaled 9y agoOpenID Connect is based on JWT: http://openid.net/specs/openid-connect-core-1_0.html#IDToken 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.
- geocar 9y agoOAUTH2+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.
- unscaled 9y agoWell, 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#CodeFlowSteps 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.
- 9y ago
- Illniyar 9y agoThat's an excellent overview. Thank you for writing it.