151–160 of 247 posts
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.
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…
Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours included)
As a concrete example: people occasionally misuse the Origin header, thinking that they can use it as a form of client authentication. The idea is that any client request from a non-whitelisted origin will fail. But any user can spoof their own Origin header, and the Origin header is primarily intended to protect users from making CORS requests they didn’t intend (because in most cases an attacker cannot coerce a browser to forge a header).
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…
Earlier quoted context omitted.
Tptacek shits on them every time it comes up. Unfortunately I can never quite comprehend what he says to do instead.
He suggests KISS: you can probably get away with plain old server-side auth, and if you really need client-side tokens, use something simple that just encrypts and signs them: https://news.ycombinator.com/item?id=13612941#13615634
Like JWT?
I feel like that argument goes around in circles.
Earlier quoted context omitted.
You've just described the JWT workflow.
No, they've described a Bearer Token workflow. JWT is a specific method that also (most times) uses Bearer tokens, but it wasn't the first, nor does it have a monopoly on Bearer tokens. I remember building a service when I was experimenting with web development that used randomly generated tokens in a custom HTTP header, and that is closer to Bearer Token (the standard) than Bearer Token is to JWT.
The open source ory ecosystem ( http://github.com/ory/ ) might have what you're looking for, but it's definitely for advanced usecases. I know a lot of people that worked with Auth0/Okta/AWS Cognito but got so frustrated by downtimes, bugs, and complexity that they moved away. But it is an option for rapid prototyping although I'd keep a "replace it" somewhere in my milestone planning. Another possibility is Keycloak…
Can you elaborate on how they "misuse" them? I don't have any familiarity with those two companies, generally curious. Thanks.
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…
I’ll recuse myself from further “nitpicking” I suppose, because this isn’t going anywhere. If you’re interested in actually following why your suggestions are a poor fit for session authentication, I’ll direct you to this flowchart: http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-....
The open source ory ecosystem ( http://github.com/ory/ ) might have what you're looking for, but it's definitely for advanced usecases. I know a lot of people that worked with Auth0/Okta/AWS Cognito but got so frustrated by downtimes, bugs, and complexity that they moved away. But it is an option for rapid prototyping although I'd keep a "replace it" somewhere in my milestone planning. Another possibility is Keycloak…
I think the distinction is that, if you intend to have a publicly accessible API, tokens are preferred vs cookies. For your own mobile clients, doesn't matter
You can choose firebase or AWS Cognito. They offer readymade sever and client SDKs for a wide variety of targets. Firebase is always free, and AWS free for 50,000 users
They offer authorization based on roles
Earlier quoted context omitted.
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.
The big objection to JWT is that it's a bearer token with no revocation support. If you're going to implement a bearer token with no revocation support, or a custom revocation implementation, anyway, then the criticisms of JWT apply just as much to the system you're building and you might as well just use JWT.
That statement is not true. JWT do support revocation. In short, servers are free to reject any token, which triggers a token refresh on the client-side. Token revocation is even an intrinsic aspect of JWT as they suport issue and expiry timestamps, along with a nonce to avoid replay attacks.
It seems some users have an axe to grind regarding the idea of having to keep track of some tokens that were poorly designed (i.e., absurdly long expiry dates without a nonce) but the solution quite obviously is to not misuse the technology. In the very least, if a developer feels compelled to use a broken bearer token scheme that does not expire tokens based on issue date then quite obviously he needs to keep a scratchpad database of blacklisted tokens to compensate for that design mistake.