It’s a good start, I always hated working with it and it always felt like a half-solution, 99% because of the reasons you and @hauleth already enumerated above. It mostly just added complexity and extra code for not much added security (if any at all).
dimitarvp
Pistrie
So what should I use if I want to have authentication/authorization for my API? What I’m really looking for is a step-by-step tutorial that I can follow, as I’m still learning Elixir and Phoenix, and these types of guides work really well for me.
1
dorgan
What’s the intended use case though?
In this thread it’s kind of assumed that this is for a website, and in such case why not just leverage old-fashioned http-only cookie based authentication? Phoenix by default even provides auth generators and CSRF protection so you don’t have to deal with any of the tedious bits. The fact that your endpoints return JSON instead of an html document does not magically make it require some special authentication strategy, so why bother?
Now if the API is either:
A- Intended to be consumed by a first-party client like a mobile app
B- Intended to be consumed by third parties
Then yeah it makes sense to discuss this.
For A, cookies are just regular http headers so you can also leverage them for your first-party mobile client, there’s almost no need to deal with a different strategy here.
For B, there’s stuff like OAuth2, this is the use case where the stateless tokens, refresh tokens and all that dance makes the most sense, and how to store these tokens is the problem of the third party, not yours.
I might be missing something important though, but really just because you return JSON doesn’t mean you have to think of a complete different authentication strategy, it’s more about who’s the party that will consume that and still assume malicious third parties are trying to own your base.
Maybe @Exadra37 has some insights on this, if he doesn’t mind the ping 
8
Pistrie
There isn’t any use case, I just want to learn how to create Elixir/Phoenix APIs as my only current experience is Express.js with a bit of basic JWT. The idea I like the most is for it to be an API available to the public, meaning that anyone should be able to create a front-end for it.
0
al2o3cr
The refresh token flow to exchange a refresh token for a new access token normally requires client credentials in the Authorization header, just like the second step of the authorization code flow where the authorization code is exchanged for an access token.
1
trisolaran
I was joking
Not an expert, but:
I have nothing against JWT a priori, I don’t think it’s “dumb” to use them. I think their advantage is simplicity. They’re simpler than creating, storing and managing tokens in your DB: you just sign the token, send it to the client and you’re done. But you pay of course for it in weakened security (number one problem IMO: can’t revoke them).
If you’re building an API for HTTP-only clients then I guess there’s nothing against using an HTTP-only cookies for API authentication, it’s certainly better protection against XSS, as explained by @hauleth. But it’s not 100% protection: if I mount a successful XSS attack against your site I can’t read your HTTP-only cookie, but I can send requests to your site and your browser will send the cookie along, thus allowing me to impersonate you and do all sorts of bad things. Successful XSS attacks are pretty much a “game over” scenario IMO.
If you just want to learn how to build authentication for Phoenix APIs then you might check out tutorials like this one. Seems pretty simple. It uses Guardian (which uses JWT), but if it’s just for learning how to build a simple API, I don’t see any issue with it. You can extend your API to use more bullet-proof security later.
0
Pistrie
Thanks for that extra tutorial. Do you perhaps have any pointers on the bullet-proof, or at least more secure ways of authenticating? Phoenix.Token gets mentioned, as well as oauth, but I’m completely at a loss because it seems like there’s a dozen different ways to go about it.
0
dimitarvp
But that’s a complete deal breaker! To me every security has to start with “the server can pull your plug at any moment”. That’s how you do security in depth: you accept the possibility that a password or a token can be stolen but you also make sure they can be made null and void at the press of a button.
I agree but there’s nothing we can do as programmers. Those holes are for browser vendors to fix. 
What we can do is follow best practices and keep up with modern developments.
0
trisolaran
Good discussion!
Ok, but then you must know that a lot of security defaults are below your expectations. A default Phoenix app stores its session in the cookie. You can’t “pull the plug” on that from the server side, if I have that cookie I can use it until it expires. Same is true for phoenix tokens.
If you want to pull the plug from the server whenever you want against a malicious client, then you must store cookies or tokens in your backend and check them with every request. Too much overhead? That’s where refresh tokens (which have been hastily shot down above) might help: you can store and verify only the refresh token and keep the access token stateless and short-lived. In this way you can “pull the plug” on the refresh token and as soon as the access token expires and cannot be refreshed, the user is logged out.
It’s all about trade-offs really IMO, complexity/overhead vs security.
phoenix tokens may be cryptographically more secure than JWT, but you still can’t revoke them. It really depends on what kind of security you want for your API. As I said, if you’re just learning how to write an API my suggestion is to pick something simple.
2
LostKobrakai
“The server can pull the plug at any moment” might be a requirement or might just as well not be. There’s certainly contexts where the latter is the case – not everything involves access to not to be leaked data – and in the end it’s less of a technical decision than one of risk over benefit taken by the business. But as always this requires awareness of the risks involved and the business value gained by taking or not taking them.
Generally I’d still suggest keeping things simple, use db driven auth/static tokens, have http only sessions where useful. If there’s business value to be had from using less secure (mostly less central-db heavy) options then there’s money for changing out a previous implementation as well.
2