First of all - I agree with what you say in the article and fully echo your sentiment. I am personally on a journey to find the best solution for the problem.
I am sure you would appreciate the complexities of building software in larger teams. We often have a situation where the API is built by one team, the front-end by another. These teams do not talk to each other. Not that they don't want to. It's just how they are structured. And both depend on an identity provider (something based on OIDC or OAuth 2.0) who is responsible for issuing the tokens. This very same API can be consumed by another team that is building a mobile App.
Now, I can take your advice and put my JWT in an HTTP only cookie. My mobile app can add a cookie header to make sure that JWT is always sent to the API.
You would also appreciate the fact that running an XSS attack on my SPA front-end is only one of the many ways to steal tokens. There are a number of documented vulnerabilities in both ODIC and OAuth 2.0 that the hackers can target to get hold fo tokens. Once they do, it does not make any difference if the API expects the token to be set in a header called Authorization or a header called 'Cookie`.
Is there a way for the API developer to protect its API without having to worry about the security mechanics in place at the consumer?
No. Unfortunately, if you are using OAuth or OIDC that's the name of the game.
I'm not a fan of either protocol due to to their poor structure and implementation issues. The burden in using these protocols is everywhere: on the authorization server, on the client, and anywhere else :(
If you're stuck using those protocols just do the best you can with the tools you have.
Why would you say that? I have been using OIDC for some time without any significant issues. Can you shed some light on why you think these protocols have problems?
The very fact that you're posting on dev.to means you're already using OAuth, as it's the only auth mechanism for the site (via either Twitter or GitHub's IdP). There's only a few ways to implement CSRF-less and cross domain credential proxying and JWT is one of them. I don't necessarily agree with JWT, since by the time you get done implementing revocation and audit logging, you're just a hop and a skip from just having the IdP store "session" since at the end of the day either the JWT itself or a token wrappered with a cookie represents the user's identity to the application. If you're not facebook or some other huge platform with potentially a gazillion identity verification requests per second, signed JWT doesn't save you much compute anyway since it's expensive to generate the token signature vs. just having the IdP do a session lookup against something fast like Redis. On the other hand, you're not autospewing the contents of your cookie jar on every request to that domain either.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.