User management with absinthe for api

Looking for an example in absinthe and ecto of user management for an api with the following:

users
permissions
role
and an absinthe middleware to verify each users permission and role.

Also looking for best practices regarding this subject(also database diagram).

This where my thinking for my current diagram is at:

Not interested in JWT or local storage.

What I came across in the Internet searches was the package doorman but it lacks the permission and role part.

Also after i finish this user management system I will make it open source and credit everybody that help me along the way.

Thanks in advance

What’s the issue with JWT - libraries or protocol ?

Big security problems and opens the way for an XSS attack that in most cases can’t be stopped. Also if you don’t have a blacklist for rejected tokens or the blacklist gets leaked your application will get crashed.
All your data will be owned by the hacker(deleting stealing your data or manipulating it).

Summary: Always use session cookies unless your are not on a browser(mobile), but even then still use cookie based session, because they are much more secure.

Some information can be found here from a security expert at okta @rdegges

4 Likes

If it’s for an API then JWT could be fine with an adequate TTL. That being said, I’m not a fan either.

If you’re interested in leveraging an existing library, then Pow has been used with absinthe: https://github.com/danschultzer/pow/issues/61#issuecomment-452797023

But there is no built in roles/permissions. I prefer to hard code roles/permissions, and would only want to keep them in the db if I were to permit users to micromanage permissions.

@alchemist_ubi has been working on an IAM library. I’m not sure how far he has come, but it might be what you are looking for.

2 Likes

Thank you for you response @ danschultzer

I was also looking at https://github.com/bmuller/pundit-elixir to see if the helpers it offers may be useful for my case.

Still have to think more about this.

Not to pile on, but I’ve been using https://github.com/schrockwell/bodyguard and it’s worked well enough for me.

1 Like

Bodyguards looks similar to pundit.

Do you have a complex user management with multiple roles?

Because i need a very complex user roles and permission management.

Thanks in advance also for your previous input @seanwash

Thanks very much again for the input and also for sharing your auth library with me. I didn’t realize at that moment that you were the actual author.

It’s a great honor for me to receive advice from someone as experienced as you.

But there is one thing that I don’t get, if we all agree that JWT isn’t the best thing why are we using it?

Thanks in advance

Because it’s stateless which makes it super easy to spin up numerous Phoenix/Plug instances dynamically without having to deal with distribution of session cache. Makes sense for e.g. API’s with very high traffic load, as soon as the instance is online it can deal with the JWT without even having to be connected to any cluster.

A cool thing is that you can even use JWT in stateful sessions, as it’s just a token. You can check the session cache at critical endpoints, and still have extremely fast responses for other places without the need to check the cache. It could be argued that it goes somewhat against the idea that tokens should be completely random strings without any information, and should only be used as a key to fetch the actual data in a K/V store. But there are probably more knowledgeable people here who can talk about what weaknesses there may be.

Azure Active Directory uses JWT for their API tokens. As a client you can then validate the generated token.

It’s probably the best for what it’s designed for, but there is a multitude of ways to handle auth. For sessions I still prefer completely random strings.