i can't see the utility of this function, because everybody save information about members on database and not in the web.config file, so we need all the time to write our own function to authenticate which checks if the user exists on the database with the corresponding password.
There are cases when you need to authenticate the user without asking him for the password. Here is the situation where I used it:
I have a website using the asp:Login control. I authenticate users using username and password on the click of the login button.
Then, I was asked to implement another type of login, parallel to the existing one (the user could choose), the one using OpenID.
So basically, after the email provider ensured me of the user's email, I automatically authenticated it without asking for username or password.
Something like:
if ((hasUsername(email)))
{
FormsAuthentication.SetAuthCookie(userName, true);
}
Related
I need to implement the equivalent of One Time password, meaning that I need the flow:
User enter contact address (phone number, email ....)
The server generates a short password, send it to the user through mail/sms/pidgin
User read the message, and copy past the code in the app.
Server authorize credential and approve login (create a session/return token to the user)
I do not want to the user to type/update/reset any other password, once the one time password has been entered, he is logged in.
I am looking at OTP for this, but all I can find for OTP is to be used as MFA in combination of the user actual password.
Is there a name for such login flow? Any literature about it?
Thank you
Such a flow is usually called a "magic link".
https://auth0.com/docs/connections/passwordless/guides/email-magic-link
https://docs.magic.link/welcome
My question is similar to What data can I save in my database to verify a user with Google sign in API?
I've built Google Sign In correctly and I get a response from the API like this:
{
"iss":"https://accounts.google.com",
"at_hash":"xxx",
"aud":"xxx.apps.googleusercontent.com",
"sub":"xxx",
"email_verified":true,
"azp":"xxx.apps.googleusercontent.com",
"email":"xxx#gmail.com",
"iat":xxx,
"exp":xxx
}
The SO link above says to save the sub field as this is a unique identifier. I can save the email/sub no problem. My question is: How do I allow this user to sign in next time with an email/password form, if they choose to do this, versus OAuth? I guess I could force them to sign in thru OAuth, then verify they're signed in and have them create a password, but I don't know if that's the best way to do this.
The "sub" parameter is only guaranteed unique for the "iss" parameter. So the combination of "iss" and "sub" is globally unique.
If you MUST store a password you will need to ask the user. Some apps put in a random-complex password for every user as some application frameworks require a password. This may be helpful if they forget they used Google to sign in for you to do you due diligence in assigning a temporary password for the user with the email address.
You should of course consider that the email address is globally unique at any given time, but could be reassigned in some cases.
We are using OAuth in our apps to login to repositories such as Google Drive, OneDrive and Box.
We allow the option for the customer to create a default user, so we use login_hint parameter to pre-populate the default user. Since the box with pre-populated username is editable, if the customer decides to modify the username, and tries to login with a different username the page is reloaded with the default username again, instead of logging in. On the second attempt the user is able to login with the new username.
Is this a known behavior? I would expect the user to be able to login the first time. This also works inconsistent, sometimes user is able to login with modified username from the first attempt.
I am creating an iOS app, and am working through the signup/login flow trying to understand how to structure my user model.
I want to allow users to sign up via facebook/twitter as well as using a standalone email/password if they don't want to authenticate through a service.
I am using auth0 to handle service authentication.
What is the standard process of storing / keeping track of my users if some are signing up through email/password, and others are simply authenticating through Auth0.
This is what I've come to so far:
My user model will contain the following properties at a minimum:
_id
name
email
password (will be blank for authenticated users)
auth0_id (will be blank for non-authenticated users)
How I will validate a user on login:
If a user who signs up manually (email/password) wants to log back in, I will check their email exists in my users table and then run a match on their password, if a match - return the user object.
If a user who authenticates through a service wants to log back in, I will make the call to Auth0, check their auth0_id exists in my users table, and then run return the user object.
Does this pose any security issues?
Comments/suggestions welcome!
I recommend decoupling your user and auth0 models from each other. For example:
User schema:
_id
name
email
password
Auth0 schema:
_id
auth0_id
user_id
I also recommend requiring a password on the user schema, and generating a strong password for users that register through Auth0. This will ensure that all users have a "standard" user account regardless of Auth0 and their continuing to have those services in the future (ex: the user deletes their Facebook account but continues to use your service – all they have to do is run through your "forgot password" flow).
Then have a standard login flow and an Auth0 login flow – the latter is the standard Auth0 flow, you check that the Auth0 ID exists and return the joined user record.
Did you consider using the email/password functionallity that is built-in in Auth0? That way you don't have to keep two different logics.
I intend to build a customized logic on Devise on Rails. Here is the logic: user can try to login, and if the does not exist, then it will create the account for the user. Just to skip the registration process.
Now sure how to hack into Devise. Please help!
Thank you in advance!
Edit: Sorry that I didn't make it clear enough: I have implement the on-create-validation on the user model to authenticate with another system. Logic is:
If success with another system's authenticator, then create a new user with the same password and login user.
Else login fail.
You know that if someone make typo he will create new account and will be mad that all of his/her stuff disappeared? When there is small amount of user then it isn't problem. But when your society will grow then it can make you some black-PR. You should rather check by AJAX call that there is user with that email/username/nick and if not then show the registration form, but on other hand this can be security issue if your users are signing in using non-public data like email or if username is different from nickname shown on your page.
Why would you want to skip the registration process? I don't see any benefits.
First, the user can enter the wrong username or password by accident.
Second, the user can enter the right username, but the wrong password. So he/she already is a registered user, but still get a new account.
Third, when a new user is automatically registered, how does the user actually now what his username or more importantly, his password will be?
Personally, why not just add "Remember Me" or "Forgot Password?" to your login form. If, for any reason, the user doesn't want to enter his login data or simply doesn't know his password required to login he can use these options.
Or, if you are working with permissions, why not just make a guest user if someone is not logged in?
What if they type in the wrong password or username on accident? Then you just automatically create them an account? IMO that would be a bad user experience. You either know your account or you don't. If you have an account and can't remember then you use the 'Forgot my ...'. If you don't have an account, then you go signup. You could implement oAuth and use accounts from a multitude of sites (i.e. Github, Twitter, Facebook, etc.) that would make it easier.