Imagine an invitation based service which allows only certain email addresses to register and then login.
As developer, I would like to provide a user a simple one-input form at the very beginning of the authentication process. User provides only email address, if email is on a whitelist, user is provided with register or login form.
My question is how can I store the email whitelist and validate if email is ok to login/register before accessing login/register form in auth0?
See https://auth0.com/docs/design/creating-invite-only-applications which gives instructions for invite only flows.
Many SaaS apps allow self-service provisioning, where users can
register themselves and begin using the app. Other types of apps,
however, do not allow such signups. Instead, the customer (typically
an organization of some type) pay upfront for a number of users, and
only the end user with the appropriate credentials may sign up and
access the app. In such cases, you can use an invite-only workflow for
authorization purposes.
Related
Users on my platform can register with email & password.
When they wish to log back in they can use a 3rd party integration (such as Gmail) to authenticate their email.
I've seen on multiple websites (Zapier for example) that even though I authenticated with the Gmail integration, they still ask me for my original password when signing in.
Why would they need my password if they already authenticated that this is my email?
Is there any security reasons to do so or is it just to make sure that even though it is my email, that I know my password for my account?
There is no need to ask for a password if you connect with a trusted service such as Google, Facebook, Apple, Microsoft, Twitter, etc, and you are in fact delegating all security checks to the respective provider. Google, for example, based on the user's account settings would be responsible with providing the user with a 2FA challenge before logging in.
It would in fact be good UX practice to not even ask the user to create a password and some websites even decide to exclude the creation of local accounts altogether. In this case, the user can just log in with the provider without the need for a "sign up" process because all OAuth providers share the user's email address if requested so you can create the account "on the fly" as needed and personalize the experience by sending a welcome email, redirecting to a page, showing a message, etc.
That being said, you can augment the login security as much as you want with original password requests, CAPTCHA challenges, encryption, IP whitelists, hit counters, cooldown periods, etc, if you feel it's justified. Would it be needed? Probably not in most cases.
I'd like to implement SSO logins for users in my Firebase web app, but only for users that have an existing account. When I add e.g. the Microsoft provider in Firebase and implement the required UX flows in the web app, anyone with a Microsoft account is able to sign in using that, upon which a new user account is created (if they haven't signed in before). I'd like to restrict this to users that:
have registered previously with e.g. an email and password login method, and
have subsequently chosen to activate the SSO login method in the web app
Is there a recommended way to prevent the default behaviour in Firebase auth for SSO so that I can check for an existing account with the same email and its approved login methods before letting the user log in and/or create a new account?
There is no built-in way to do this in Firebase Authentication, as it makes no distinction between sign-up and sign-in for OAuth users.
The typical approach to implement this is to create a list of the allowed users somewhere that both your app and your server-side logic can find it (like in one of Firebase's databases), and then check against this so-called allowlist in both your client-side and server-side application code (and security rules) after the user signs in and before executing any other application logic for them.
In the application itself, you could show this as "unable to sign in" to the user, since (despite you calling the Firebase API and signing them in there) they have not completed the sign-in into your application itself.
I want to allow my users to register themselves by verifying otp that will be sent to email and phone number simultaneously and allow signup after verification. I am using azure adb2c user flows,
I am open for changing auth provider to Auth0 or firebase if they satisfy this use-case.
When it comes to Auth0, you would need to build out the functionality in your application code for a one time password to be sent out to the email and phone number simultaneously. I hope this helps bring some clarification. Thanks!
We are developing an SPA - full client base javascript application and need to authenticate our users to get access to the internals.
As I found from the search we can outsource our authentication mechanism and use Google accounts for that. I learned from this site
https://developers.google.com/accounts/docs/OAuth2Login -
How to deal with Google API and mechanism for authentication.
In the short word, we need:
send request to google url with params to ask user to allow SPA use their personal data
in case of success we get a token from Google
we may use this token to get access to API we were asked and work with it.
This is described well and I understand it and have some JS code to make it happen.
What I do not understand.
I have an application with it's private data. I want use user's e-mail as the login, or user id (doesn't matter how to call it) to access app's internals, such as user's created tasks, user's profile, etc. So, to display user's created tasks in my SPA I need query database with the user's e-mail.
I imagine the next scenario:
user click Login with Google button
we obtain an token - this means user was authenticated successfully
we persist user and his e-mail to work with SPA
when user click Logout we clear all access data
Where should I persist this data?
In case of Forms Authentication I understand that we pass login/password to server and if they match the database we create Forms Ticket and store it in cookie.
Is there any similar case with Google's auth? If I'll store user's email in cookie I think that's not very good from security reason. If I'll save a token - I'm not sure why I need it and how to use it in my SPA, I'm not using any Google API after authentication.
Do you have any example case how do we build our process in similar cases?
Thank you.
If all you need is the user's email address, then you would be better off using OpenID instead of OAuth. OAuth provides access to a user's account and services, scoped to a specific resource or set of resources. OpendID is designed just for logging into a third-party service. You can then extract the user's ID and email address from the OpenID login. Note: The ID will always be sent but the email address has to be explicitly requested during authentication.
Google also supports a hybrid OpenID+OAuth scheme that lets you piggyback OAuth requests on top of an OpenID login if there is some resource you need to authenticate to. Take a look at the authentication document to get an idea of how both protocols work and which is better for your scenario.
Once you have the email address returned, you probably shouldn't persist it in a cookie. The normally recommended way to handle it is to add it as a session parameter. That way only the session cookie is stored on the client, and the server can use it find the values it needs. This answer has a good explanation of the differences and when you want to use sessions versus cookies.
I was just wondering, I want to associate a Twitter and LinkedIn account with my systems accounts. Which would allow them to post to interact with them without needing to log in to the other systems.
Is there a way to store the social (twitter / LI) usernames and passwords and associate them with my system and vis versa.
E.g. If I login using my native details (email / password) I can access the API features of my social network accounts?
Thanks in advance,
Chris
I can't speak for Twitter, but with LinkedIn you could follow this basic workflow:
Register an 'application' with LinkedIn. Your site will use this application for all communication with the LinkedIn API.
Have the user authorize your site (your application really), to access their account via the LinkedIn API.
Retrieve the user's unique LinkedIn ID, as well as their access tokens, and store those in your user account database, associated with their existing account.
Then, when they return and log in to your site, any calls you need to make to LinkedIn can be done via the stored access token, rather than having to have them manually allow you to have access again.