I have an application that used the Cognito user pool for authentication and authorization. I want the admin to login into the system without going through email verification. but all end users must go through the passwordless sign-up sign-in process.
my question is can I use the same user pool to implement both use cases or do I need to use separate user pools for admins and end-users?? I also would like to know whether it's possible to use same login endpoint for both admins and end-users
Thanks in advance!!!
You should really include a code sample and what you've tried so far, but I had to work with Cognito recently so I think I can give an answer anyways.
If you're creating both users via AdminCreateUser, you would use this payload to create a verified email for the user. Keep in mind, having a verified email is separate from having a confirmed account. You can call this admin endpoint to confirm users: (https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/admin-confirm-sign-up.html).
UserAttributes: [
{
Name: 'email',
Value: email
},
{
Name: 'email_verified',
Value: 'true'
},
]
Related
hi I need to perform testing for my cloud function, but I need to create dummy anonymous account in Authentication emulator
I need to create anonymous account that has last signed in data 2 months ago. how to do that?
to create account using email, I can use code like this
admin.auth().createUser({
email: "jdoe#gmail.com",
emailVerified: false,
password: "secretPassword",
displayName: "John Doe",
disabled: false
});
how to create anonymous account programmatically using Admin SDK that signed in at certain time?
I don't think it is possible to set the creation data and time in the new account. As far as I can determine those values are managed by automatically when an ID token is generated when a user signs in to a (new or existimg) account from the client.
I am trying to write some REST api functions to perform some basic user administration. I cannot seem to find the secret sauce for re-enabling a closed e-signature user, using either the Admin API or the E-signature API.
I saw a post that said just send the create user POST with the same username and email, but every time I do that, I get a new e-signature user, and not a reactivated closed user. I would appreciate any tips anyone could share.
Thanks
BL
Perhaps try issuing an Update User request, which allows you to specify the userId of the user account you want to (re)activate. For example:
PUT /accounts/{{accountId}}/users
{
"users": [{
"userId": "00000000-0000-0000-0000-000000000000",
"sendActivationEmail": "send"
}]
}
I'm following the Microsoft tutorial Create a user (local or social account). So I'm trying to create a user from HTTP call, for this I'm sending a similar payload to the tutorial:
{
"accountEnabled": true,
"creationType": "LocalAccount",
"displayName": "Alex Wu",
"passwordProfile": {
"password": "Test1234",
"forceChangePasswordNextLogin": false
},
"signInNames": [
{
"type": "userName",
"value": "AlexW"
},
{
"type": "emailAddress",
"value": "alexw#gmail.com"
}
],
"userIdentities": [
{
"issuer": "google.com",
"issuerUserId": "MATxTNg5MzYyMzMyMNY1Njc="
}
]
}
My question is how I can generate the issuerUserId as it is necessary for the Google supplier to recognize the user. I'm trying with a random value encode with base64 but when I run the user flow the user it's created again with a duplicate email. I suppose Google don't recognize the issuerUserId.
Update:
Base on Allen Wu answer:
issuerUserId is a unique user identifier for the issuer. You can set any valid string (don't be duplicate) for it.
I create this issuerUserId with a valid string: 12345678909823456789
As before, I create successfully the user and the source show as Google:
But when I want to log in the account with Google provider
The user is duplicated:
I assume instead of launch Sign in process Azure/Google don't recognize the account's issuerUserId and launch the Sign-up process, for that reason that's why I think issuerUserId might be created by Google.
Some notes:
I'm changed the emails for demo emails, but that is the current
behavior.
I'm only using Google authentication, I don't using email and password fields of the login, because the purpose of the app is only for Social Authentication (Google specifically)
I'm using Sign up and sign in (Recommended) user type flow.
If you have more thoughts about issuerUserId that can help me, let me know, I'll really appreciate.
It's not true.
Based on my test, the user flow won't create a new user which has a duplicate email. (the previous user is created via AAD Graph)
issuerUserId is a unique user identifier for the issuer. You can set any valid string (don't be duplicate) for it.
And Google / Facebook or any other social idp won't verify it, because this user is created in B2C. It's an B2C local account. ("creationType": "LocalAccount")
Create an B2C local account doesn't mean this user has been created in Google.
I guess that you add Google idp into the user flow and are trying to create a new user in Google rather than B2C.
You should click on the "Sign up now" in user flow to create the local account. Kindly check it.
Update:
As I have mentioned above, the user you created with Azure AD graph is an B2C local account. You should use the default sign in feature to log into that user. B2C will verify your credential.
But when you click on the "Google" to sign in, in fact the Google will verify your credential and will associate your Google account to a new B2C account. It's not a local account.
So they are two different accounts. You can verify this by changing the password of the B2C local account. After changing the password, you still need to use the old password to sign in with the "Google" option. But you will need to use the new password to sign in with the first user (B2C local account).
You can use GET https://graph.windows.net/myorganization/users?api-version to get the two users and find that the issuerUserId of them are different.
I'm trying to create a stripe connect account using my firebase functions backend when the user signs up but keep getting this error Express accounts may only be created via the OAuth flow I know the error seems self-explanatory that I need to use the standard OAuth registration method but in the Documentation it states that custom types can be created by the API and presenting the OAuth for every user who just wants to send funds and not receive is just annoying am I doing something wrong for the API not to create it? Or is there a workaround to not have to show the OAuth for users who just want to send funds?
exports.createStripeCustomer = functions.auth.user().onCreate(async (user) => {
const customer = await stripe.customers.create({email: user.email});
const account = await stripe.accounts.create({type: 'custom', business_type: 'individual', individual: {email: user.email}, requested_capabilities: ['card_payments', 'transfers'], email: user.email});
return admin.firestore().collection('stripe_customers').doc(user.uid).set({account_id: account.id, customer_id: customer.id});
});
Express Accounts and Custom Accounts are distinct types of accounts when using Connect. You can create Custom Accounts using the API, but Express Accounts must be created via OAuth.
The main difference is that Express Accounts have access to the Stripe Dashboard and can be updated in some ways by the end user, while Custom Accounts are entirely managed by the platform.
The issue seems to be being caused by me not specifying the Country in the stripe.accounts.create function. Once I did it created the account.
I am trying to automate creating tickets in Salesforce. For this, I am using API with Python. I have got the Client ID and Client secret for my registered python Application. I have read many questions and as per the security purpose, I do not want to use the "user-password" flow for my script. Is there any way that I can only use "CLIENT ID" and "CLIENT SECRET" to get the access token where I can pass this access token in bearer header for other calls
import requests
params = {
"grant_type": "client_credentials",
"client_id": client_id, # Consumer Key
"client_secret": client_secret, # Consumer Secret
}
r=requests.post("https://login.salesforce.com/services/oauth2/token", params=params)
access_token = r.json().get("access_token")
instance_url = r.json().get("instance_url")
print("Access Token:", access_token)
You'll always need a SF user account. There's no way to just make a backend system talk to SF system. Salesforce treats everybody as user so you need to waste an account for "integration user" - but in return you can control access to tables, columns, functionalities just like you control real humans' access. This goes all the way down to the underlying Oracle database and database user privileges.
Whether you use OAuth2 flows (including client secrets) or maybe some certificate-based authentication - there will be always some element of "username and password" required. Best you can do is to make sure your app doesn't need to see & store the password, instead showing normal SF login prompt and on successful login user is redirected to your app to continue with known session id...
There might be something you'll be able to automate more if your app and SF use same Single Sign-On but broadly speaking... You have to either let users login to SF via your app or create the tickets as some dedicated admin user (and then you store this user's credentials in your app)