Roll your own auth (split thread)

True, I did originally put signed and wrote a sentence describing that, but JWT is technically the same way (although Guardian encrypts it), but changed it, unsure why. ^.^

But yeah, tokens/jwt are for passing data around that may be public, especially JWT’s as they are often read by the clients as well (though the Guardian implementation of that breaks the ability to do that), just signed so you know it is not tampered with. :slight_smile:

If something is supposed to be secret then keep it on the server itself or pass via a secondary channel directly to another server is what I’d always say.

1 Like

Thanks for the lengthy comparison, @OvermindDL1!

Yes, we could easily rewrite it, but wouldn’t it be nice to have a library to do that (kinda like Guardian, but with Phoenix.Token) to make more people adopt Phoenix.Token? Kinda like a ready-made solution that you can mix deps.get. I think having to write it yourself might be off-putting for some (although I do not want it to be another left-pad case, but I guess it’s not going to be that trivial).

I’ll see if I can get a PoC running.

I’m using Guardian for an API endpoint, do you think is an overkill?, When i sign in a user i send him a JWT token, and now for every request he must have that token in the header and with Guardian i verify, ensure authentication, etc.

Here it is: phoenix_token_plug. Currently it only handles simple VerifyHeader and EnsureAuthenticated. I kind of extracted it from my project, and I’m using it in the project with the path: config in mix deps.

Still unpublished on hex, though; I’m still working on the tests (need help: how do you generate a Phoenix.Token without a Phoenix.Endpoint and secret_key_base? Or, how to best generate those two on the fly in the test file?) and probably wait for feedbacks first.

ping @OvermindDL1 :wink:

I fully aware this, but as far as I know… Most people only need basic auth (sign up, sign in, sign out), especially for a newcomer who wanted to learn. And why not make auth system than can extended easily? So more advance user can fully use its feature. It’s not an excuse.

Again, as far as I know… Most .NET developer use identity on their app, because most tutorial is uses it. And it’s integrated deeply on its core. It’s not that complex if you ever tried visual studio before, I encourage you to try it first.

Then create micro framework, not full MVC framework :slight_smile:
With full MVC framework, people expect more than basic CRUD generator. (Don’t repeat Rails mistake. I think it is just basic CRUD generator without its gems. Sorry.).

Yes, I know… But yet, I still cannot find what I’m looking for. Such as auth and pagiation. Yet it is very basic funtionality.

Even laravel done a better job IMHO :

Like I said, so much hassle. Not very intuitive for a modern full-stack MVC framework.

I’m not against this… I am part of other community too. But using too many 3rd-party lib also not a good practice. Excessive use of 3rd-party makes the size of a Phoenix process larger than it needs to be. This can slow down performance in production. In addition, it’s also add user frustration eventually.

Bear in mind that each lib you bring into your application may in turn have dependencies on other libs, and those may in turn have dependencies on other libs, and so on

Community can make unique features for Phoenix, for people who really need it. No one against that.

You know you can always choose right? That’s what open source mean. I can choose to use django built in auth system (it’s time-tested and battle-tested, and reviewed by thousand devs), I can choose to use 3rd-party lib, or I can even create my own if I have many spare time.

Our opinions are not objective (both yours and mine). So, we shouldn’t really be debating what we think.

I will repeat one thing though: Authentication/Authorization are really orthogonal to a web application framework.

To me it makes sense to not have authentication bundled in Phoenix or Rails or any web framework. To you it may not make sense. However, the phoenix devs focus on what they think is essential (I am not a contributor). And Phoenix presence and channels are more valuable than authentication. You can roll your own authentication with some effort, however you can’t do the same with Phoenix presence or channels.

If phoenix had every little feature that everyone needed (think of the asset pipeline), it may not have had things like Presence or Channels.

1 Like

It should yes! You should make such a library! :slight_smile:

I have to admit that I’ve written such plugs multiple times over a few projects too, but each are a little different in different ways, and they are all simple enough that I’ve not had a need to push out a library myself, but if a generic library were made and were able to handle a vast amount of cases, then all the better. :slight_smile:

A bit, however if you intend for your api endpoint to be used by services then the JWT could be useful for them, and having it unified with the front-end simplifies code. I’d still opt for phoenix token though unless ‘another’ server is sending data to your api endpoint while crafting secure data, that would be a great use for JWT, but just for front-end or api access, not so much, but not harmful either other than taking more space on the wire.

Hah, that was fast! ^.^

I’ll go over it and see how well it would fit in to my systems and submit issues/pr’s for areas that it would not. :slight_smile:

Sounds like you want Ueberauth with a generator for a front-end template then. Ueberauth handles (via plugins, and it has a lot) username/password (that plugin is called ueberauth_identity, and it is so simple that it is used as the template to make new plugins too), google, facebook, github, and a ton more. However, Ueberauth handles nothing on webpages, it only supplies the API endpoints to allow for full automation in those setups, you just respond to a callback that you assign to it and it gives you a success or failure struct with information that you wanted (like from google, or the username/password they used). What would be fantastic is another project, say something like ueberauth_frontend, that just adds a mix task to setup a whole set of basic templates for login pages and such, something that someone can <%= render :blah %> into their normal templates. There could be whole page varieties, pop-up varieties, etc…, and all it does is delegate to the ueberauth strategies. :slight_smile:

You could add in a lot of other composable helpers like password reset and such too, flesh out the whole ueberauth_identity plugin with a new more powerful one with more abilities. I’m not a fan of systems that copy templates and such in to your area by default, rather I think templates of the templates should be copied in only when requested in piecemeal, otherwise it should be entirely composable.

Authentication is a very easy task, especially with libraries like ueberauth for the oauth and such versions. I use an ueberauth_ldap adapter at work and I use the gmail/github/etc… ones on a personal website (Hmm, I do not use username/password anywhere now that I think of it…).

Impressive feat, Dear Sir! I’ll just put this here: Passwords are Obsolete :wink:

Hah, nice! ^.^

Though I’m a fan of 2fa to a service that I hope knows what they are doing, like google or facebook or github. I do not want to duplicate work that I could easily get wrong, while also creating more hassle for the users. ^.^