Here's my question. To access our app, the users must be invited.
This means, we use an admin web app to create the user account in Firebase and we send him an invite to download the app and use it.
Now the next phase, how can we send to the newly created user his credentials?
Our first idea was to use a temporary password. We could send the password by email to the user and ask him to redefine his password at his first logging.
His this a good idea? I guess it's not
Is there a better way?
Thanks for the help.
T
There is no way to prevent users from authenticating with Firebase Authentication. So instead of depending on pre-creating of the accounts, you should ensure that only authorized users have access to the data.
For example, when using the Firebase Database, you could keep a list of authorized users in the database:
/authorizedEmails
t4ncr3d3#hisdomain,com: true
puf#hisdomain,com: true
And then you'd check the auth.email variable against this list in the database's security rules.
Instead of pre-creating the account, you could then simply email the user an invite to the app. E.g. an email with a link like http://myapp.mydomain.com/signup.html?email=t4ncr3d3#hisdomain.com
Then when they click the link, pre-populate the sign-up form with the email address you sent the message to and call createUserWithEmailAndPassword().
You could use the new (as of Nov 2016) firebase-admin library (java or node) to programmatically create users from your server side - see this link for details.
After that, you could send the email and password to the user via email, and allow only email based password logins. Unfortunately, you can't force uninvited people to stop authenticating with your app, as they could manually invoke the APIs used to create a new account on their own, as you see on the same page. However, you are under no obligation to provide a login mechanism via your UI. They would have to use their browser to type and invoke the JS needed to create the account.
If you are OK with people forcibly creating accounts, but you would like to lock down their access, you could do something similar to what Frank mentions in another answer by using admin control of the database to restrict access to those users you have created and invited with a special flag in the database (that only you can modify using the admin SDK) that acts as a gateway into your app. If you perform the security properly, that should prevent those whom you didn't invite from using the app, even if they can effectively authenticate with it.
Related
I am building an application that will be used by end users in multiple organizations to create and send envelopes for signatures. I am trying to figure out the correct authorization workflow. For this example, say I am manish#example.com.
My understanding of JWT is that JWT will impersonate manish#example.com when any of these 1000's of end users in different organizations send envelopes. Is that correct? But if so, won't they need to authorize the app to impersonate me when they first try to create an envelope? How will these users get my credentials? Would I have to share my credentials with all these end users of my application? Can they log in with their own credentials instead? But if my application is impersonating my own credentials to send envelopes on behalf of these end users, why do I need permission from these users to use my own credentials? After all, in the JWT workflow, the redirect URL does not return any information about the identity of these users of my application.
So, if my app impersonates me, how do end users get my credentials? And, if my app impersonates me, why can't I give this permission to the app once and for all at the time of creating the app? Why do end users have to permit me to impersonate myself?
On a related note, JWT is working great when I use my own personal DocuSign API credentials to authorize my app in testing. But when I try to use my own organization credentials to authorize the app, I get the following error. I also get this error when I try the AWT workflow. How can I fix this error:
Sorry, but we’re having trouble signing you in.
AADSTS50105: The signed in user 'manish#test.edu' is not assigned to a role for the application '225d2ddd-e3a3-4bed-a310-8a9b8786363e'(Docusign Test).
Help in setting up the correct authorization workflow would be great.
JWT enables developers to request a token on behalf of some user without that user having to log in.
That means that except for the first time when the user have to consent - there's no web UI required to obtain a token.
JWT tokens are for a specific user in a specific account and it's the GUID of that userID that is used to uniquely identify a user. If you have multiple accounts - you will have to ensure you use the right userID for the right user for the right account.
Note also that users in DocuSign have different permissions profiles and may or may not have the access required to do what the API is trying to do.
Finally, clarifying one last thing, you wrote :
when any of these 1000's of end users in different organizations send
If you have thousands of end users that will be sending envelope (not just signing them) then JWT is probably not the best choice for you. You can still use it, but you will need some way to know the userId of the user which means you'll need some uber-auth JWT user that is used first or keep tables of users (I assume users can be added/removed etc.) it's not an ideal way to do things.
I want to use Okta to safely store my users names and passwords; however, they also have information such as (to be general) age, birthday, graduation date, interests, etc. to be stored as well.
The Okta API does not store this info so upon account activation I need to create an entry for this user in my MongoDB database immediately.
Is there a way to detect this event? Thanks!
If this is extremely roundabout I am totally okay with taking a new approach too; however, I don't see much wrong with my current method if it is in fact possible.
I am using Node and ExpressJS to communicate with Okta using express-session and the oidc middleware.
A common solution would be to separate the user profile data from their credentials. So first, you have a user create an account or sign in with Okta. After they are signed in, you retrieve their profile data. If the user has no profile data in your webapp, you force the user to fill our their profile before they can use the webapp.
New user flow would look like this:
User clicks on "create account"
User enters in email/password in Okta
Your backend stores the user session
Your backend attempts to locate a user profile for the user. None found (first time user), so it restricts the routes the user can access.
Your frontend forces the user fill out the profile before accessing any other screens
User fills out profile and submits
Frontend POSTs profile to backend, backend saves it
Frontend and backend lift all restrictions, app continues as normal
I'm learning Node, doing authentication stuff at the moment with passport.
Say my server has 2 pages, a public home page with various login options, then a super-secret page(and perhaps more) that is only accessible after authenticating.
If I'm only going to be using 3rd party strategies, is there any reason to have a database?
I know that you'd obviously need one for local user's id and pass, but if the server exclusively relies on 3rd party authentication, would session persistence be enough things to work? Or are there still various things that you would need to save for some reason (apart from logging) ?
Could you do without a database, sure... but in this case what is the point in authenticating at all? All you would be proving is that the user has a Google account which anyone can set up for free in a matter of minutes.
If your content is super secret then chances are you want to have a database of users (email addresses and the like) that have permission to see the content. By authenticating through OAuth you will be given an access token that will allow you to fetch the authenticated users email address. This can then be looked up against your user table to see if the user is registered and if your app enforces it, check whether the user has access to the page requested.
OAuth is proving that this person is the owner of the Google/Facebook/Twitter/Github Account. You can use this knowledge to sign someone in against a database of "local accounts" based on email used at sign up, assuming you validate the email on sign up locally.
I have a JSF application I have configured with a JPASecurityRealm I use to log users in. This works fine with native user accounts. I now added a login with facebook functionality. When users login with facebook for the first time, I create them a new native user account for our website with the data returned by facebook. Which works fine, but I have problems authenticating the user on our server now. Usually I use request.login(userID,userPassword); but because users don't have a password with their native account now, I don't know how to authenticate them? Is there something like request.login(userID), which logs the user in without needing a password?
but because users don't have a password with their native account now,
I don't know how to authenticate them? Is there something like
request.login(userID), which logs the user in without needing a
password?
You could generate a random password, persist it and notify them. Then just also give them the possibility to change it later .
I'm trying to use Windows Azure Access Control to avoid the security risks in using usernames/passwords in my app and to simplify the authentication. However, this is a site that can be used by medium or large companies that may wish to "pre-authenticate" users. In other words, they may want to bulk create users by putting in the users' Windows Live IDs and create their accounts automatically, before that user has ever signed in through Azure ACS. I could accomplish this by sending that user an email with a link to a one-time-use page to create their account, but I am hoping to do something a little more seamless.
What I'm trying to do is equivalent to how Team Foundation Service (*.visualstudio.com) lets you add users to a team project just by putting in their Windows Live IDs and once you do, they can log in and access the project, even if that user had never signed in to TFS previously.
What I don't understand is how to do that using ACS and System.IdentityModel. I can use the nameidentifier claim to uniquely identify a user, but how do I get a nameidentifier for another user through a given provider?
I'm sorry if I'm not explaining this well, so feel free to ask questions.
Not really an answer but just wanted to share my thoughts on the issue.
The problem with ACS and Windows Live authentication is that ACS never returns the user's email address. All we get back from ACS is a token telling me that the user is authenticated. This token is created based on your ACS realm (i.e. if you change the ACS realm, a new token will be created by ACS for the same user). Again, the admins of the company who are using your application can enter the email addresses of the user but there's no way to get that email address back from ACS.
Just thinking out loud :), there're a few things you could do:
You use ACS for authenticating the user and then use Windows Live REST API to get more details about the user using the token sent by ACS. By using Windows Live REST API, you can get more details like name, email address etc. about a user. Or you could use just Windows Live API for authenticating the user. I'm not 100% sure but I think this is what Team Foundation Service does. Do take a look at http://zud.io as it does the same i.e. uses Windows Live API.
Another idea would be to create some sort of invitation tokens. In this approach, admins would "invite" folks. They would create invitation record by providing the name, email address of the users and the application would create unique invitation tokens. The application could then create an invitation link using which users would come to your application and authenticate themselves. Once authentication is done, you could look up the invitation record and retrieve user information from the database and create user record and associate the authentication token with the user record. The issue with this approach is that a user may not use the same Live Id as provided by the administrator. For example, I have at least 3 live ids and if I have that invitation link, I could sign with any of those live ids and the application won't be able to stop me from registering.
Yet another idea would be to use Windows Azure Active Directory (WAAD) instead of ACS. You could consume Graph API in your application to create new users for your clients. You're still not managing user names and passwords as that is done by WAAD. The two issues I could think of there are - a) As an end user, I have to remember one more username/password combination and b) At the time of login, I have to provide my credentials in myusername#yourtenantname.onmicrosoft.com which to me personally is a big hassle.
We too have been going through the same pain and for now we have decided to go with approach #2.
Hope this helps.