Comments (12)
@RobStallion technically all user data is sensitive (according to GDPR)
Yes, in the context of GitHub a username
is public
but imagine we are building something for the NHS which would have a "forum" where vulnerable people could interact with and seek help from medical professionals. The person's chosen username
and especially their name
are highly personal and need to be encrypted and stored appropriately.
The Programming Phoenix Book (v1.4) is good for the technical implementation especially contexts, but it's not written from a maximum privacy perspective (and is certainly not GDPR-compliant) please treat the book as a "guide" not a "gospel" when building Auth.
For our purposes all people-related data is sensitive. There is no advantage to splitting out "credentials" into its' own table as we will always select and decrypt the Name of the person (in order to display it in the UI) on a successful login. This is why a login flow diagram is necessary. π
Rob, if you have time today we should pair on a Diagram to clarify this for ourselves and others. π
- Auth should be a logically separate Umbrella Application that is fully self-contained.
https://elixir-lang.org/getting-started/mix-otp/dependencies-and-umbrella-projects.html - (for now) it should require the creation of a separate database to store user-sensitive data.
Having a separate database forauth
is the best thing for privacy.Note: we may re-visit this later if we want to give people the
<option>
of using the same DB as their main Phoenix App, but for now it should be completely separate. - We should have a
Auth.session_verify
function which should be it's own Hex module that should be included into any app and used to verify a session validity.- Check the JWT info is valid:
- Expiry
- User agent & IP Address (though we may be lenient on IP address changes because #30 ...)
- Force re-authentication if session has expired.
- Reject any request where device/agent hash does not match JTW.
- Check the JWT info is valid:
- If the Application (using auth) needs access to more of the "user" (personal) data we can create an API request to retrieve that data. e.g:
GET /auth/personal_details
We must figure out how to integrate this with Phoenix Sessions: phoenixframework.org/blog/sessions
Please share the link to the StackOverflow question you opened on this when you can.
from auth.
Diagram is public on the interwebs so anyone should be able to see and edit it:
@RobStallion if you have time to walk through the requirement for sending an email with a link to "verify email address" with @Cleop please go for it. the issue is: #35 (thanks!)
from auth.
@nelsonic I have created 2 basic phoenix applications called regular_app
and auth_app
.
regular_app
is pretty much just a default phx.new
project. I have added httpoison
to the deps and and using it to make requests.
auth_app
is the app you make following the programming-phx-1.4 book (up till chapter 5 as that is where they cover auth). It has basic login/logout functionality.
So far I have been able to get regular_app
to send a post
request to auth_app
with json of a username and password. That user can then be verified in auth_app
and a json response can be sent back to regular_app
.
I know that this ins't exactly what we talked about when we made the login diagram but I figured we would need to be able to do something similar to this for a newsletter registration type event anyway so it would be good knowledge to have.
Next step
Have regular_app
link to auth_app
's login page. Once login has been completed in auth_app
send the user back to the page they came from in regular_app
(look into http referer as a poss way).
Once I am back in regular_app
, make a GET request to auth_app
to check the session is valid. My first guess is that regular_app
will need an "auth_plug" type of thing that will handle making this request for all incoming requests but we'll see.
from auth.
I have updated my test apps.
regular_app
has a link on the landing page that links to auth_app
Once in auth_app
I get the http_referer
like so...
referer = get_req_header(conn, "referer")
render(conn, "new.html", referer: referer)
and send it to the login form which has it as a hidden field.
I log in as normal in the auth_app
. If log in is successful however it redirects back to regular_app
like so...
redirect(conn, external: referer)
auth_app
creates puts the user_id
in the session
on login like so...
def login(conn, user) do
conn
|> assign(:current_user, user)
|> put_session(:user_id, user.id)
|> configure_session(renew: true)
end
Not sure on best way of sending this info back to regular_app
at the moment.
from auth.
@RobStallion worth opening a separate issue e.g. in learn-elixir
and describing the problem as a "SSCCE" so that you can ask it on SO/Elixir Forum and capture the answer?
from auth.
The idea of using ueberauth/guardian is a non-starter for me. π
If you read through the docs for Guardian there is a lot of text but not a single diagram. π€·ββ
See: https://github.com/ueberauth/guardian/blob/guides/introduction/overview.md π
How does someone explain a complex topic like Auth without any diagrams? π€¦ββ
Something as simple as this: https://github.com/dwyl/hapi-auth-jwt2#understanding-the-request-flow would be a lot better than large blocks of text and nothing visual.
This is not a "niggle", it's a symptom of a bigger problem: complexity.
The first line of the docs informs me that I'm going to have to create an "implementation module".
Why? Why isn't there a default
one already included that I can use immediately.
We can simplify our Auth by an order of magnitude by just building exactly what we need from scratch.
We want our "setup" instructions to be:
- Decide where you're deploying your instance of
auth
. (e.g.localhost
, Heroku or AWS) π‘ - Define the Environment Variables π
(it might take someone a few minutes to assemble all the API Keys they need
e.g: Google API keys for Google Auth and AWS keys for sending emails) - Deploy! π
That's it. No more configuration or steps required. Get back to building the features of the app
.
Obviously, to achieve this level of "batteries included" simplicity, we have to do a lot of work on our end.
Next: dwyl/app#268 (comment)
from auth.
@RobStallion thanks for opening this question! πΊπ»
We need a diagram for this.
from auth.
@nelsonic After reading programming-phx 1.4 my thoughts on how the auth app might work have changed some and I wanted to run my current thoughts passed you.
They talk about separating a users sensitive and non-sensitive information into different places in the application and database. All the non-sensitive info (username, name, etc) is put in the users table while the sensitive info (email, password, etc) is put in the credentials table.
Auth will:
- be an application that a user requires as a module
- create a credentials table when a user migrates
- handle logic around email and password (figured this would be the best place to start and possibly expand this later)
- update the conn from the parent app with session/assign info.
this is thinking of the auth app in the most basic way at the moment and not including the other tables that it will need to contain (e.g. sessions table).
Pros
Using this approach people using our module will:
- have a lot of flexibility around the rows that their users/people table contains
- be able to see and access the credentials data in their database
- have access to all functions that handle auth (login, login_by_email_and_pass, etc...) will be expose. Users will just to call the functions where needed without having to worry about any implementation details/logic.
Cons
Using this approach people using our module will
- need to create their own user table which will hold all the info besides the email and password.
- need to create the login/logout forms
Please let me know your thoughts on any of this. This is my no means a finished idea. I also have a SO question open relating to how we would best implement something along these lines here.
from auth.
My stack overflow question is here.
from auth.
Auth Diagram: https://docs.google.com/presentation/d/1PUKzbRQOEgHaOmaEheU7T3AHQhRT8mhGuqVKotEJkM0
@RobStallion please LMK if you can access/edit it.
from auth.
Have been doing a fair amount of reading up on session vs token based auth...
- https://medium.com/@njwest/jwt-auth-with-an-elixir-on-phoenix-1-3-guardian-api-and-react-native-mobile-app-1bd00559ea51
- https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide
- https://security.stackexchange.com/questions/81756/session-authentication-vs-token-authentication
And the impact that this could have on the way we want to build auth.
The Phoenix book shows us how do auth with session auth, as seen in this comment above
Guardian is a token based authentication library for use with Elixir applications and can be used to create JWTs.
@nelsonic You mentioned that you did not want to use Guardian in this comment but said it was a closer approximation to what we need.
I looked into how it is used in elixir apps (I have never used it personally so needed to look at some examples. The first link above is a good example) and they have made the implementation of it fairly similar to the examples from the book, e.g. they create an auth plug and pipe incoming requests that need to be verified through said plug.
My current understanding of how JWTs are verified is through the "secret" in them. JWTs are made up of header.payload.secret
. This secret or signature is what the receiving app uses to verify the request.
I think that we would be able to create an api this way fairly easily. E.g. a user would login by sending a post request to auth_app
, auth_app
would do the logic and send back json (a JWT).
However, if we want to redirect users to auth_app
and then redirect back to regular_app
as mentioned, we will need to pass the JWT back in the redirect. I am not sure how we will do this ATM but I think we should be able to do it will Plug.Conn.put_resp_header/3.
Once back in regular_app
we will need to be able to verify the JWT when needed. I assume that if regular app has the access to the same secret/signature
used in auth_app
we will be able to verify the JWT without having to make further requests to auth_app
(unless we need a users data of course, in which case we could have a simple api set up for this)
@nelsonic Let me know your thoughts
from auth.
GOTO: #42
from auth.
Related Issues (20)
- Groups UI/UX HOT 1
- Phoenix.Template.UndefinedError Could not render "live.html" for AuthWeb.LayoutView HOT 1
- Chore: Fix Failing Auth Tests HOT 3
- Review how auth application works
- Chore: Sample `people` for testing `groups` on `localhost` HOT 3
- Chore: Use `statuses` [in-memory] in `auth`
- Auth: Deploy Demo Version to Fly.io HOT 11
- Bug: GitHub Username Not Returned by Auth ... π€¦ββοΈ HOT 7
- BLOCKER: Internal Server Error when Registering with Email Address! HOT 5
- Error `expected a binary but got: nil` HOT 7
- Technical Question: should we use a `JWT` for `AUTH_API_KEY`? HOT 8
- Feat: Auth Setup Wizard `#discuss`
- Feat: Use `Gmail` to send Email!! π§ π€―
- Tech Question: Do we even Need an `AUTH_API_KEY`? π π€·ββοΈ HOT 5
- Feat: Copy `AUTH_URL` to clipboard
- Feat: Allowed List of URLs for each `AUTH_API_KEY`
- Chore: Generate ERD for `mix phx.gen.auth` HOT 2
- Chore: Update the `people.email` to use `Fields.EmailEncrypted` HOT 4
- Feat: Re-create Login Screen Using Tailwind CSS HOT 2
- Feat: Delegated Auth
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from auth.