When my users update their email address on the settings page of my application, I send them an email with a link to mydomain.com/verify_email?username=COGNITO_USERNAME&code=123456. When a user clicks on the link in the email, the user's default browser will open the specified page, which, in turn, will parse the URL and call Auth.verifyCurrentUserAttributeSubmit('email', code) (it does not use the search parameter username specified the URL).
However, this process only works if the user is authenticated, i.e. if the user's email client opens a browser tab or window on a device and browser where the user has previously signed in since any call to verifyCurrentUserAttributeSubmit needs to authenticated (see Amplify source).
How can I verify updated user attributes (preferably using Amplify) without requiring users to be signed in so that they can confirm updated attributes using another device or browser?
Related
I'm sure I am missing something here but...
I have an angular application that allows users to fill out forms. The application calls a backend NODEJS service that has a responsibility of building the HTML envelope and document to sign. This back-end service does not have access to a browser.
I have 2 options for flow:
User fills out form -> clicks sign button -> back-end service called to gather the url for the user to redirect to in order to get a code back (consent) -> USER DOES NOT LOGIN TO DOCUSIGN -> redirect back to application -> get token with users code -> prepare envelope on BEHALF of the user -> send application the ceremony URL -> user redirects to ceremony -> signs document -> redirect back to application.
*User fills out form -> clicks sign button -> back-end service called to create envelope and tell DOCUSIGN to send an EMAIL to the user which I don't want to sign up for DOCUSIGN. (Effectively removing the need for them to create an account with DOCUSIGN because I am sending an email and they can authenticate him by knowing he is coming from his own email). -> user signs document through email -> (Would be nice for application to get redirected back to but not necessary)
All examples and chats I have seen discuss only having to login one time. Well in flow 1, I don't want the USER, signing the document, to login or have to make an account for this one signing. And in flow 2, I can't seem to grasp how to keep the back-end service authenticated if it is a BACK-END service. It's headless. No Browser.
These guys are so large that I figure it's something I'm not grasping here.
I understand to impersonate the user, I would need his consent. And possibly... because they don't KNOW the user without him signing up for an account to verify his email, they can't offer consent to a user they can't verify email with. So if that is the case, I would want to authenticate my BACK-END user to send emails so they can just click the email, it MIGHT verify in DOCUSIGN without having to sign up for account, and offer the contract to the user to sign on the spot from the email WITHOUT asking for credentials or NEW account.
If you are going to answer this with a link back to DOCUSIGN authentication examples. Or suggest use a JWT to authenticate from BACK-END services... please explain in detail the steps to authenticate my BACK-END user and keep him authenticated without using a web-browser or how to use the users consent from a redirect from DOCUSIGN without the user having to EVER create an account.
I have tried sending the user to the redirect URL with success if they already have their credentials cached in browser or already have a DOCUSIGN user. The flow works fine there. I get the users code, exchange it for token, create envelope, redirect user to ceremony, redirect back to application after signing complete.
I have read a bunch of articles that all point back to DOCUSIGN help with authenticating 1 of 3 ways with a browser. I need no browser login, or a better understanding of how to avoid the user creating a DOCUSIGN account.
Thank you so much!
Signer, user that signs, does NOT need to have a DocuSign account. They do not need to log in to DocuSign in order to sign. They can sign via email or embedded in your app, but they do NOT need to have an account or log in.
Your app's back end needs an access token to make API calls. This doesn't change the headless nature or the fact that it's back end. A token is a long string that your app uses to authenticate. This authentication is tied to a user in DocuSign that has an account. That is NOT the user that signs, but the user that make the API call. You have to have a user that makes an API call.
You can get a token using JWT authentication and your back end can generate it using the Node.js SDK (npm package) without the need for UI or for anyone to log in.
I have github enterprise configured. I use keycloak for authentication.
Sign up/ login flow is like this,
Users click sign in with SAML from github enterprise.
Then they are redirected to keycloak login page.
Where they can choose github.com for signup.
After successful authentication from github.com users are redirected to github
enterprise.
Now a new user has been created in keycloak with username as of github.com username and email as of github.com email.
But in github enterprise, user's username is created by parsing the first part before the # of email id and user's email id is not getting updated in github enterprise user account even though github enterprise is receiving email id from keycloak.
Users get the following notification, saying them to add one email address.
If an user don't add their email, they don't get email for events like organization invitation, password reset.
This not what i want. I also not what the users to manually add email id to their account.
I want get github enterprise user's username and email to be the same as of keycloak.
How can i achieve this ?
We have extracted saml response from keycloak to ghe by inspecting the /consume request in browser network. When SAML response is decoded (using samltool.io), we identified that keycloak is not sending email attribute to ghe.
Github used the following attributes for updating profile information. So keycloak needs to send attribute in variable specified in this field.
We have found that there is some builtin "Mappers" available in client which can be used for sending some specified predetermined attributes to client applications.
Select your client -> Mappers -> Add builtin. Select the required mappers and click Add.
Open x500 Email and set "SAML Attribute Name" to the variable same as the variable name set on github. Provide some Property and Friendly Name.
Now you will get email address in user's account.
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
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.
Background
We are integrating third party email solution into our site. When a user goes to the Mail page it must be automatically authenticated at the Mail site.
For now, the Mail link points to our page which automatically submits a form with the user's login and password. After clicking submit the user is redirected to the Mail site with authentication cookie.
The problem with this approach is that we do not want the user to see his Mail password, because we generate it automatically for him and there are some sane reasons not to show it.
Question
Is there any way to receive mail authentication cookies without sending the login information to the client and performing form.submit operation from the client's browser? Is there a better way to do what I'm trying to do?
Edit
Of course "I am trying to do it programatically". Looks like that there are no sane solution except pass these login/password to the client. Looks like we must accept that user can see his mail password and somehow make sure he cannot use this information to change password to some other value we will not know.
Edit: I didn't read the post correctly, I thought he was trying to login to a remote mail application, not one hosted on his own server. Ignore this answer.
When you login to the remote third party mail website, they will create a cookie (since HTTP is stateless, it's the only way it knows the user is authenticated unless they store some kind of session ID in the url). When you send the user to that site, the site needs to know how to authenticate the user. Even if you logged in from your application and grabbed the cookie, you can set a cookie on the users browser for another website. The only way for this to work is if there is some kind of development API on the third parties website you can hook into, or they allow you to use session id's in the URL.
Possible solution but has a security risk
If they allow you to set a session_id in the URL (for instance, PHPSESSID in PHP) then you could grab the session ID and append it to the URL when sending it to the user. I don't really like this idea since if the user clicks on a link in an e-mail, the new page will be able to check the referrer and see their session ID in the URL. This can become a huge security risk.
Lookup topics related to your mail vendor and "Pass-through Authentication." You did not mention what vendor/software you are using for your web mail solution, so I can't help you very much there. Other than forwarding the user's information (in a post request) to the login handler.
Generate unique IDs before sending an email and put them as hidden instead of username/password into form. Make them disposable (usable only once or usable once before successful entering the site)