Whitelist users in Auth0 - auth0

I've created an app that uses Auth0 for login. I have google-oauth2 enabled for the app. What I would like to do is have a whitelist of approved users who can login but all I see is a Users page where I can block users after they've logged in. Is there a way I can configure Auth0 to restrict Google users (and all users except approved ones). Thanks....

There are a few options that you could use in order to implement what you want:
Using Auth0 Rules. Maybe you can try to create a Rule that check the user's email adress against a whitelist of adresses, and allow only access if the adress exists on the list. Rules docs
Using Auth0 Client Grants. It will allow you to grant access to specific users, based on their userId. Grant Types
Probably you could try to create a Group and assign users to that group and allow just them to log in or using auth0's connection .
You could try to use that method based on email invitation too Email invitation

Related

aws amplify: How to add user to a auth group when they signup to my app

I am making a app that requires to scope the users to a specific access level.
For Example there are Three groups
Admin FUll CRUD
Teacher Table Specific permissions
Student Table Specific permissions
While Admin will be created From the Console and that admin will create Teachers accounts.
When anyone signs up to the app I need them to be put in a Students Group by default.
Using the Amplify CLI when adding the auth category in the default or manual workflow you can setup a lambda trigger to add a user to a cognito group automatically upon signup.
Walk through the options until you reach this step and select Add User to Group:
$ Do you want to enable any of the following capabilities?
❯ ◯ Add Google reCaptcha Challenge
◯ Email Verification Link with Redirect
◯ Add User to Group
◯ Email Domain Filtering (deny list)
◯ Email Domain Filtering (allow list)
◯ Custom Auth Challenge Flow (basic scaffolding - not for production)
◯ Override ID Token Claims
See this section of the CLI documentation for more details: Set up lambda triggers

Auth0 - how to create a user without a password, or how to include password in verification email

We have a web app (SPA Angular app talking to a .Net Core Web API) which uses Auth0 as the authentication server.
Now, I'm not sure if this would be an "invite flow" or "invite-only flow", or something else, but basically, a user will go to our web app, and create an account on our system. Our API then creates an Auth0 account for this user using the Auth0 Management API. This user is then considered the Administrator. She can then create as many users as she wants for her staff. For each user she creates, our API creates an Auth0 user using the Management API.
Since, as far as I'm aware, a user must be assigned a password at the moment of creation (i.e. you cannot create a user without a password), the administrator must pick a password for each user she creates.
Additionally, each time a user is created, Auth0 automatically sends out an email to that user asking them to verify their email address. When the user follows this link, it takes them to the Auth0 login screen where they have to fill in their email address and password.
My problem is that, unless the administrator tells them what password she picked for them, there's no way of them knowing.
My question is: is there a way to defer picking a password until the user logs in for the first time? So, when the administrator creates the user, she doesn't pick a password. Then, upon the user's first login, they pick their own password.
Alternatively, if a password MUST be set at the moment of creating the user, could this password be displayed to the user in the email verification email? I would essentially treat this as a temporary password, as I would also require the user to change their password upon first logon in this case.,
Thanks

Microsoft graph is remembering the user after authentication

I'm using Microsoft graph in my Android project to authenticate users.
I'm doing so via this method:
https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v1-android
after a successful login Microsoft remembers the user email, so next time when user is trying to login it will suggest to use a previously logged in account. If user chooses a previously used email, a password is not required.
Problem raises when we have a single device where multiple users need to login via Microsoft. In this case new user will see the email of previously logged users and can select their email and log into account without entering any password.
My question is how can I avoid this behavior and close the session after each login?
Thank you!
You can tell ADAL to request credentials again by switching PromptBehavior from Auto to Always:
// Perform authentication requests
mAuthContext.acquireToken(
getActivity(),
RESOURCE_ID,
CLIENT_ID,
REDIRECT_URI,
PromptBehavior.Always,
getAuthInteractiveCallback());

Association of OAuth between providers

I was looking at Khan Academy and I'm wondering how their authentication works (probably many other websites have it the same).
When you login with facebook account that has email "aaa#gmail.com", you completely logout, open another anonymous window, and login with google account that has the same "aaa#gmail.com" email, you log into the previously created account.
My questions are :
Do they make association to account based on email your social account has ?
I'm sure their solution is secure, but is this common and normally doable so there won't be any possible exploitations ?
I'm using a system of Oauth2 to grant access to my app, dvouch
First you have a registered user in your website, with an unique email.
So what basically happens is:
User visits your website (website doesn't know who the user is)
User clicks to login through one of the Oauth2 providers
Your website proceeds to start a "OAuth2" handshake, it redirects the user to the provider oauth endpoint, along with some information, like what scopes you're asking for (email, personal info, public info, etc), the url to send back the user after the authentication is done, your application tokens (that are registered in the providers app dashboard), and so on.
Let's say the provider you chose was facebook. Facebook receives your request for an OAuth2 authentication. It also receives the scopes you're asking for, which url you want the user to go to after being authenticated, and your application credentials
It checks that the credentials you're sending are valid, that the callback url you're asking the user to be sent after also matches what they have registered for your app (so that someone can't simply steal your app credentials and have users redirected somewhere else) and if everything is fine and dandy, it will then present the login window to the user. This login is happening on the provider's page. Not on your website.
The user logs in (inside facebook or google not your website). The provider sends them back to the call back url you specified in the beginning of the handshake.
You (your website) receives the user back with a bunch of information, such as the email of the user who just completed the Oauth2 flow.
At this point you use the email that came in the callback and identify the user through the email. Since all emails are unique, and since your user had to be registered with that email on the provider, you are safe to assume he's the owner of the email.
(technically things might happen a bit differently)
It's basically very secure as long as the website has the regular security measures. Of course if someone has access to your Facebook(wtv) account or email they can login as if they were you, but that would happen either way they offered Oauth or not.
Then as long as you verify you're logging in the correct provider's website (like facebook's or google and not something else) you'll be fine since no one else will be able to see your login. Since a "scope" of authorizations has to be passed as well you as a user can also see what the application is asking for (email, access to your inbox, wtv) and decide if you want to grant those scopes or not, if you decide not to grant access then facebook will not pass back that information, which in turn renders the process safe.
The only way it wouldn't be safe would be if you had malicious software installed in your computer to log your activity and in this case you would be screwed either way.

How to Set Up Account Linking for a Skill using Alexa API from Amazon?

I am trying to figure out how to link a skill with a custom user account. Here is what the documentation says:
Account linking flow for implicit grant (for use with custom skills):
In the Alexa app, the user enables the skill.
The app displays your
login page right within the app, using the Authorization URL you
provide when registering your skill on the developer portal. When
the companion app calls this URL, it includes state, client_id,
response_type, and scope as query string parameters.
The state is used by the Alexa service during the account linking process. Your page needs to keep track of this value, as you must pass it back later.
The state is used by the Alexa service during the account
The client_id is a value defined by you when you set up account linking for the skill in the developer portal.
The response_type is always token for the implicit grant flow.
The scope is an optional list of access scopes indicating the level of access requested. You define the set of scopes to support when enabling account linking for your skill.
The redirect_uri is the URL to which your service redirects the user once the user is authenticated.
The user logs in using their normal credentials for your site.
Your service authenticates the user and then generates an access token that uniquely identifies the user in your system.
Your service redirects the user to the specified redirect_uri and passes along the state, access_token, and token_type in the URL fragment.
The Alexa service validates the returned information and then saves the access_token for the Alexa user.
The user’s Alexa account is now linked to the account in your service, and the skill is ready to be used.
Here is what I get form Amazon:
{
"client_id":"my-client-id",
"response_type":"token",
"state":"some_long_string",
"redirect_uri":"https:\/\/subdomain.amazon.com\/spa\/skill\/account-linking-status.html?vendorId=W5TGH673R
}
Based on what I read above I am redirecting back to:
https://subdomain.amazon.com/spa/skill/account-linking-status.html?vendorId=W5TGH673R&state=same_long_string&access_token=something-I-made-up&token_type=Bearer
Unfortunately this doesn't seem to work. Basically I get: Unable to link your skill
Any ideas?
I ran into a similar issue, and I had to use a hash instead of an ampersand before the token. My redirect url is:
https://subdomain.amazon.com/spa/skill/account-linking-status.html?vendorId=W5TGH673R#access_token=something-I-made-up&state=same_long_string&token_type=Bearer