I'm unsure why the distinction matters that was brought up in the post. It really comes down to what do you need to support, and how much weight you can swing.
Are you a small time supplier, and want a major retailer to integrate with you over API? good luck. The decision really isn't yours, if you want to get paid, you integrate.
I think the reality is that most developers would rather use an JSON API instead of EDI. EDI is sometimes talked about as just X12 / EDIFACT, but the protocol is baked in as well, which causes more headache (who wants to build an EDI stack?). X12 was built during a time where VANs probably connectivity, and caused per character, so everything was positional based and inferred. Modern APIs are descriptive, and easier to use.
(fd: I work for Orderful, a company that provides an API and then translates it to EDI so you can easily work with any trading partner)
My dad passed away with dementia in 2019, spent a lot of time in nursing homes and also making decisions about the care of my father. I actually got to see this first hand with his caregivers in his facility. The requests to put him on different drugs required me to do a lot of research, validation and getting out of pocket advice from a medical professional that wasn't associated with the care facilities.
As someone that has gone through this, there is a fine line to walk between doctors operating under their Hippocratic oath, caregivers, and patient wishes. My dad was prescribed meds that weren't helping his quality of life and had really bad side effects mentally and physically through the the mid-stages of dementia.
Being in the authentication/authorization space for a while, this couldn't be truer. If OAuth 2.0 was a compelling differentiator from your API standpoint, they are doing it wrong.
I love how Ajit keeps saying 'it does not happen' where traffic is limited or blocked. It was limited, we saw this by Comcast with Netflix back in 2014.
This is what we are getting ready to get back into. I do not want to have an internet where the ISP can hold me (the consumer) hostage to other companies to increase the ISPs bottom line. It isn't a good experience for the consumer, it isn't a good experience for providers of media and apps.
Twitter gave the police information about the phone number which registered the account that sent the seizure-triggering gif
AT&T gave the police information that is was a Tracfone prepaid account with an associated toll record that was an iphone
Apple gave them access to his cloud account which had all the incriminating details needed including email / picture of him with his drivers license and data about the victim
Bad is relative, it is bad compared to other more secure methods. But if you can't guarantee that your users have a smartphone, SMS is still a needed option.
I'm sure Dropbox is going to get a lot of flak for this. 2FA based on the provider that they use may not have been cheap. Authy is $0.09 an auth, if you integrate with Twilio, you get SMS charges that vary on price based on country / provider.
The easiest/cheapest solution is to roll your own TOTP and build an app. This is useful for web, but may be pointless on mobile (if the mobile device is unlocked, then you have access to the TOTP app or SMS).
Business people probably looked at the cost per user and couldn't offer it at a lower rate.
It doesn't really matter where you start, as long as you can relate to the product and its customers. I've seen great PM from every beginning. My beginning was a normal comp sci background -> dev -> customer success manager (any support role is a great segway into product management role) -> PM. Having managed many PMs, it boils down to this:
Can you be an advocate for your customer for your product, regardless of intercompany demands?
Can you communicate your vision for what needs to be built effectively across the whole company?
Those are the two main skills that I try to distil for any PM that I hire. There is a 3rd which I call the auxiliary skill (these can be taught easily, hence auxiliary).
How do you validate your assumptions, remove cognitive biases to come to the best decision about the priority on what should be built when?
And a fourth, which comes down to background and personality:
Can you be a swiss army knife and help wherever the team needs you?
The product I currently manage is a developer tool, so taking a look at an example based on the 4 points:
1. Can you relate to developer pain points, market problems with identity, create great developer experience and understand where there are holes in the current product?
2. How can you use the tools at your disposal to communicate what we need to build to the engineering team, marketing, and executives. Technical and non-technical folks alike, even for a technical product that is sold to devs.
3. How can you manage feedback / signals from sales, developer evangelism, customer asks, and visionaries to create a roadmap
4. Demonstrate how you have needed to step out of your comfort zone to get the job done.
When interviewing, having a developer background is a must (but it is only a must because my product is currently catering to the developer persona), but replace a developer product with a dental product that is sold to dentists. That hiring manager is going to want someone that more than likely understands dentists and their pain points that the software is currently solving for. They could come from, office manager, dentist moving to software (it happens), someone from the insurance industry... you see the point.
Hope this helps, I'm always happy to help and advise. Snag my twitter handle from the profile and shoot me a DM.
"The U.S. Marshals Service (USMS) offers property for sale to the public which has been forfeited under laws enforced or administered by the United States Department of Justice, its investigative agencies (Drug Enforcement Administration, Federal Bureau of Investigation, and Bureau of Alcohol, Tobacco and Firearms), and certain other federal law enforcement agencies. "
My guess here is that bitcoin is considered property and not currency, and there are laws around this.
"Sleeping animals are incredibly vulnerable to attacks, with no obvious benefit to make up for it — at best, they waste precious hours that could be used finding food or seducing a mate; at worst, they could get eaten."
It seems pretty obvious that sleep had an evolutionary advantage to conserve energy when the species couldn't be productive. For example, human sleep during the night because we can't forage / hunt / find a mate during the night because our vision requires light.
It isn't about the vesting periods, it is about the exercise period. Vesting periods are fine in most cases.
The exercise period is usually 90 days, if you leave a company.
What happens a lot is there is no liquidation event for years meaning that an employee with shares needs to make a decision fast to convert or lose their shares (which they earned) and that cost $$$. I've seen time and time again, where people get locked in because they need to drop 4-6 figures to exercise their shares.
> If the employee loses the stock when he's fired early, then the company has a huge incentive in firing him a day before he vests, and thus he should regard the vesting compensation as nonexistent.
I've seen this happen a few times in SV where employees are fired 1-2 weeks before their vesting period. Sad when it happens. Not saying that all times it is because of the cliff, but people talk and are aware of companies that have done this.
All of these points are sound. There are some benefits of using a JWT over a session identifier, though. And I think that most of these were covered in the comments of your first post.
We have an implementation of JWTs @ Stormpath for Token Authentication. We help a lot of customers with token authentication / user management and Stormpath hold a whitelist of all unexpired tokens.
In the Stormpath SDKs, there is the ability to locally validate the token for speed or validate against our API to make sure the token hasn't been revoked.
A common strategy for our customers is to always validate an access token locally, but force refresh against the Stormpath API. This is a good way to not incur state in your application (Stormpath will keep the state for you).
The Stormpath Integrations (like Express / Spring / Laravel / etc) use cookies to store the tokens because we have been advocating for cookies as the JWT storage mechanism for a while:
Always happy to get feedback. Again, this article was written back in 2014, and will be updated.
In regards to your advice about id_tokens and access_tokens. Usually, what I've seen in most attacks is that if a malicious user can get one, they can get both.
A lot of your points though are valid outside of using JWTs. Open redirects vulnerabilities should be plugged and sanitizing user input should be looked at regardless of what you are using in a web application.
Thanks, Evan. these are all good points, I'm surprised to see this on HN since it is an old article I wrote.
In regards to the replay attacks, if you are using JWTs in a 3 party setup, and they are validating JWTs locally (not sending them back to a validation endpoint), the jti claim won't be enough.
Thanks again for clearing that up! Considering this blog post may still have a use, I'll update it soon.
Are you a small time supplier, and want a major retailer to integrate with you over API? good luck. The decision really isn't yours, if you want to get paid, you integrate.
I think the reality is that most developers would rather use an JSON API instead of EDI. EDI is sometimes talked about as just X12 / EDIFACT, but the protocol is baked in as well, which causes more headache (who wants to build an EDI stack?). X12 was built during a time where VANs probably connectivity, and caused per character, so everything was positional based and inferred. Modern APIs are descriptive, and easier to use.
(fd: I work for Orderful, a company that provides an API and then translates it to EDI so you can easily work with any trading partner)