I'd like to implement a passwordless auth flow for my mobile app that only requires a user clicking a link in their email to log in. Similar to how Slack handles auth. I'll be using node and jwt for this implementation.
I think I've come up with a secure design, but I'm sure I'm missing something. I would love some critique from the community š.
Here we go:
User opens the mobile app.
We check to see if user has a token in their local storage.
If they do, we add that token to their headers and send to the home page of the app.
Else, we prompt them to enter their email to get started
When they click "Submit", we POST that email address to the requestMagicLink endpoint on our server.
The server checks the database for a user with that email address
If we find a user with that email, we take the id from that user
If the user does not exist, we create a new user, and get that id
We use JWT to generate a token with the id, and our secret that expires after 1 hour
We send that token to the user via a link in an email.
Upon being clicked, that link sends a GET request to our server at the magicLogin endpoint with the token in a query param
We verify that the token is correct using JWT and our secret.
If it fails verification, we redirect the user to the screen where we prompt them with their email to get started.
If it's successful, we generate a new JWT token using their id, and our secret that doesn't have an expiration, then pass that back to the user in the params of a URL that redirects them to a success page in our app.
The app takes the token from the param and stores it in local storage until the user chooses to logout, and the user is redirected to the home page.
The requests to the api all now contain the token in the headers, and the user is good to go.
Related
I am doing service integration with DocuSign platform using JWT Grant auth type. DocuSign account has multiple users setup.
My service is SendEnvelopService and one of the important request param to the service is user email. SendEnvelopService need to impersonate user with given email-id when calling DocuSign and send envelope in behalf of that user. Note that every request to SendEnvelopService will have different value of email request param.
I have following questions around it -
Question#1) Since I need to impersonate different user every time (based on email id in my request), I assume I need to get new JWT auth token every time, before making actual api call. Is that right? Is it usual and ok to request new JWT auth token so frequently before every api call? Does it raise any integration concerns with DocuSign?
Question#2) In my request, I have email id of the user to impersonate. I don't have user's GUID which I need, to get JWT auth token and impersonate it. Is there any api that I can use to get user GUID by email id? I wonder what kind of authentication will be needed for such api because I don't have JWT auth token yet.
One idea I have is may be I need to setup one admin user in DocuSign and keep admin userId (GUID) in application config. Now I have 2 users, one is admin user and another is request user which I have email from the service request. I can following steps -
Do requestJWTUserToken impersonating admin user. We get
oAuthTokenAdmin
Using oAuthTokenAdmin make
https://developers.docusign.com/esign-rest-api/reference/Users/Users/list
api call to get userId (GUID) of request user email.
Now do another requestJWTUserToken impersonating request userId. We
get oAuthTokenUser
Now make actual api call using oAuthTokenUser and to send envelope
Go to:
https://admindemo.docusign.com/
Log in with your demo (sandbox) credentials.
Then you have two options:
If it is only for you, simple thing is to click "API and Keys" page under Integrations on the left nav.
You will see this:
You can also click on "Users" on the left and select the user you want, any user really, doesn't have to be you.
then you'll see it under this:
For your first question, no, you don't have to do that. You can use the same user for all API calls. Especially if this user is an admin, then you can do all API calls under that context.
I'm using a Express Nodejs backend + React frontend set up and tried to implement a "Register / Signin with Google" function, but I do not understand what to store in the database after the user is authenticated. In the ordinary register with email approach, I send the email + password to the backend when I register and check if both the email & password match when the user login.
However, I don't know what to store in the db if one is registered with Google. I have already implement part of the google auth with google by following this tutorial in the frontend side, here's my code:
import * as queryString from 'query-string';
const stringifiedParams = queryString.stringify({
client_id: 'MY_CLIENT_ID'
redirect_uri: 'http://localhost:8000/protected_home',
scope: [
'https://www.googleapis.com/auth/userinfo.email',
'https://www.googleapis.com/auth/userinfo.profile'
].join(' '), // space seperated string
response_type: 'code',
access_type: 'offline',
prompt: 'consent'
});
const googleLoginUrl = `https://accounts.google.com/o/oauth2/v2/auth?${stringifiedParams}`;
return (
<a href={googleLoginUrl}>Login with Google</a>
)
But then what's next? I've successfully pass through the auth process and redirected back to the protected_home page. But this only means that this user is a google user, what kind of information should I store their information in backend so that it indicated that the user has registered an account in my backend with this google account?
Also, is is possible to move the logic above to backend? Since google will redirect back to my redirect_urilike this http://localhost:8000/protected_home?code=CODE_IS_HERE, I need to browser to extract the information in CODE_IS_HERE. So it seems impossible to move the login logic to backend, any solution?
What you need to save is user's unique id, his email or phone, and some other user data for your project.
This is just to know if the user already registered or to know the current user in backend.
From backend, you can just set a middleware to verify the token assigned from google.
Then you will get the user's id and you can find a user from your database, if exists, the user is authenticated.
Signin with google.
Get redirected with CODE
Send CODE to backend
Backend will get user id and email with the CODE using google api.
Save user and generate token.
Send the token back to your frontend.
Then the login or signup process is finished.
Basically you should not write it from scratch as there are libraries that deal with Oauth2: PassportJS, openid-client, Grant, OAuth2-client-js. Those should handle all the below steps except storing actual details in your own database.
In general there are some basic steps when implementing third party oauth2 authentication:
Understand well how Oauth2 works https://www.rfc-editor.org/rfc/rfc6749
Redirect to your server from client (react)
Request authorization by redirecting to Google
Get authorization code which will be added to a url in a redirect from google back to your server
Exchange code for an access token (POST)
Use access token to get user profile details from Google (POST)
Save user details if they do not exist yet in your database - in theory you could skip this part
Create session/token and send it back to client (React) - it is another redirect.
You could also not store any user details on your server and just pass back the token obtained from Google to your React app (client), but then you'd need to check if it is valid on every request to your server. Which is why it is simpler to create your own session token and send it to the client.
There are more details as this is quite a topic to start with but RFC6749 should fill in the gaps.
Iām a little confused as to how JWT authentication works. Once a user is able to log in, my express server is responding with a token, which I store on the client side in local storage. With every request, I send that token. My question is, how do I limit a user to see his/her specific data (e.g., user profile)? Is the token alone able to determine which user is requesting the user data on the server side or would i have to send the username along with the token? Is this secure?
The JWT token will contains 3 parts, one of them called a payload and you will use it to store the user's id when he logs in. When the user sends a request with his token you will decode it and grab the id from the payload and then with a query to your database you can get the user's profile.
how do I limit a user to see his/her specific data (e.g., user
profile)?
If you get the id from the token's payload then you can compare it with the id of the profile that the user wants to see, if they are the same then it means that he wants to see his profile.
Is the token alone able to determine which user is requesting the user
data on the server side or would I have to send the username along
with the token?
No need for username, the token alone is sufficient because it identifies the user.
Is this secure?
Read this: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ there are other opinions of course, try implementing best practices and I think you'll be fine.
I am working on a REST API backend service for an app that uses both email and facebook login. Lets just pretend this app is a todo list app and a user can sign in and add notes which they could later view on may different devices.
The "Login with email" is pretty simple, the app would make a request to:
URL: /v1/login
Params: email, password
Then the serivce returns an access token if all this information is correct so we know the identity of the user creating, updating or deleting a note/list item.
Now for the facebook side. I've seen several differnet answers all over StackOverflow and Facebook's documentation. Some people say, just pass in the id and login the user with the matching id. This would mean calling the login function from the Facebook SDK and just keeping that id to send in a request.
URL: /v1/login/facebook
Params: id
That would work but seems highly unsecure. Anyone could get someone else's Facebook id and just send a request to the server. Facebook's documentation mentions also using the account email. We'll what if the user ever changes their email on Facebook, they could never login to this app again. Another hint of security would be passing in the token from Facebook every time. Since those tokens can change or expire, there really wouldn't be a way login past the expiration date.
The final method I know of would be passing in the app secret:
URL: /v1/login/facebook
Params: id, secret
This seems by far the most secure, if you are using https to connect to the server. The downside to this method is, what if the Facebook secret token is ever reset? I mean you could always make a call to the server to request and check if token was reset and if so pass back the new one. But then if anyone had access to the endpoint to check out of date tokens, it could give them the new secret token.
I know we are dealing with the internet here and there will always be security flaws and there isn't a perfect way to do this. But what is the best way?
Try to send facebook_token for that user.
URL: /v1/login/facebook
Params: facebook_token
and service side make a service call to facebook graph api to get information about that user using facebook_token.
get the facebook id from that response and use it to provide data to that user.
I'm building a apllication with NodeJs. My app have 1 login form.
When user A login successfully, I save username in session of Express.
And now I want when another user is B, login with that username, the user A 'll be logout, he 'll have a messager alert 'This account was login in another place' and user B is login.
Anyone can help me please. Thanks
Save the the user in for example a database, create a token for the specific login session and add this to the user in de database. Switch this token each login.
With each request check the authentication token (you can store tokens in local storage), then you can check if the token is up to date (active) or not.
Once another user logs in the token will change, and so on.
If you want the logout to happen without making a request you will need to use socket.io