I am working on Yoodle and I am logging into a provider which needs a dynamic token after the login in. When I fill out the form, my provider redirects to another page giving me a number to encrypter in a electronic device. The electronic device is a safenet.
I am trying to follow these instructions.
I don't know if I need to invoke again the POST /providers/providerAccount or invoke PUT /providers/providerAccount
Pass the provider's login form with valid credentials to POST /{cobrandName}/v1/providerAccounts (Add Account API).
You have to poll GET /{cobrandName}/v1/providerAccounts/{providerAccountId} (Get Provider Account Details API) until you get MFA form.
Pass the MFA form with valid values to PUT /{cobrandName}/v1/providerAccounts (Update Account API)
Finally poll GET /{cobrandName}/v1/providerAccounts/{providerAccountId} (Get Provider Account Details API) to get final account addition status.
Related
Any Cognito User Pool gurus out there? I've been using Cognito for a while now but this one has me a bit stumped.
We allow users to sign up and sign in using social accounts like Facebook which are set up as Identity Providers in the User Pool.
Users need to complete a custom registration form before they can use the main app - we don't use the hosted UI for login or signup
One step of the custom registration process allows the user to indicate which social provider then want to use
This allows us to pull back the users email, first and last names from the social provider which is great - we use a cognito client and callback to do this currently
But in doing so, this provisions a user within the Userpool before the registration process is complete - in fact this makes sense- in order for Cognito to provide us the user info it needs to have called into the social providers /userinfo endpoint to populate the user data
So, the issue we now have is that whilst the user is half way through the registration process I have a confirmed user account - eg. before the user has completed the registration process
This is an issue because a user could sign into the the app using their social login without ever have completed the registration process
So as I see it I have two options:
PostConfirmation Lambda trigger which uses the cognito-idp SDK to disable the user just after it was confirmed
Don't use Cognito to obtain the user info like firstname, lastname, email, picture etc - however this would require us to write a solution for every current and future social provider which isn't something I'm keen on
Am I missing something obvious?
Thanks in advance!
I would say PostConfirmation Lambda trigger is a good approach - however instead use adminDisableProviderForUser to disable the user from signing in with the specified external (SAML or social) identity provider
adminDisableProviderForUser
You can later call adminLinkProviderForUser to link the existing user account in the user pool to the external identity provider.
adminLinkProviderForUser
An alternative solution is to prevent the user from signing in if they have not fully completed the registration process via a Pre Authentication Lambda Trigger checking for a unique identifier with respect to your completed registration process
The simplest solution in the end for us was a Pre Token Generation Trigger in Cognito like this:
exports.handler = async (event) => {
if(event.triggerSource==="TokenGeneration_HostedAuth") {
//check db/api etc to see if we have a valid registration stored for user
if(!hasCompletedRegistration) {
//throw auth exception which we can catch on the frontend to inform user
throw new Error("REGISTRATION_NOT_COMPLETE")
}
}
return event
};
For username/password sign ins the TriggerSource will be TokenGeneration_Authentication
For federated/social sign ins the TriggerSource will be TokenGeneration_HostedAuth
Account Linking provides several ways of linking users to their own accounts such as their Google account or Twitter account.
I chose OAuth in Actions on Google website to do OAuth 2.0 Authorization Code Grant for obtaining access token in exchange for data resources. When I linked a user to a Google account Google Sign-In enabled, the fetching of user information was easy because the data is stored under payload, but OAuth implementation does not seem like it produces user data under payload inside User object.
So should I make an API call to the third party to fetch the user data and store that personal data to a database in this case? I wondered if there is a way that Google prepares on behalf of developers. If not, then greeting a user who visits my app again by saying 'Hello, {person name}' gets tedious...
You have two options with Account Linking.
In the case you describe, you're providing an OAuth endpoint and getting an auth token from the Assistant, and you are responsible for taking this token and using it to determine who the user is so you can get whatever you know about him. The token is one that you issue and control, so presumably you have that info in your database already. If you are reusing a token from another service, that service should be able to tell you who they are.
It sounds like you're using using a Google Sign In, however, in which case it is easier to use Google Sign In for Assistant. Once the user has signed into your service (either through an app or webapp) and granted permission to your service, then they will also be able to gain access through the Assistant. You will get an id token which can be decoded to get profile information about the user including their Google ID and name.
From Yodlee's put providerAccount API documentation here
It says that I have to pass in loginForm data along with user's credentials:
5. If the credentials have to be updated in the Yodlee system, one of the following should be provided as input to this service:
a. LoginForm
b. Field array
6. The loginForm or the field array are the objects under the provider object that is obtained from the get provider details service response.
7. The credentials provided by the user should be embedded in the loginForm or field array object.
Questions
Does this mean I am expected to save or somehow have user's bank credentials stored?
When I go through the refresh flow on Fastlink, it somehow pre-fills the credentials and all I have to do is just click continue; how does Fastlink do that? if Fastlink can do this, my guess is that there is a programmatic way to do this
PUT providerAccounts can be used for three things:
You can initiate an update an account, this means you are asking Yodlee to connect to the bank and retrieve the latest details using credentials that Yodlee already have for that user's account.
You can update credentials(equivalent to edit flow of Fastlink), this is used for updating the password into Yodlee system if the user has changed their password at the bank website.
You can pass MFA information if required(for MFA sites) while updating or editing accounts.
Though, to answer your question:
1: No, you should definitely not store user's bank credentials. If your need is just to update user's account, you can initiate that update without passing loginForm or fieldArray. And if the use case is that you need to update user's password, you should ask the user to provide their credentials at the runtime.
2: You should just call PUT without passing any loginForm, that's what Fastlink refresh flow does.
Our DocusSgn integration is currently a two step process:
the user clicks on "Login to DocuSign" whereupon they are redirected to "https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=00000000-0000-0000-0000-000000000000&state=00000000-0000-0000-0000-000000000000&prompt=login&redirect_uri=www.stackoverflow.com/app/callback" (for example) where they login, so that we can get an authentication.
we have the templates populated from DocuSign using the authentication. The user selects the template and clicks "Go to DocuSign" where upon a popup takes them to "https://appdemo.docusign.com/documents/details/c921ac4b-fdae-48a9-a70e-5d8a4e3e0089" for example.
The problem is that the user is forced to login both times. The expectation is that after the initial login during step 1, the user would not need to login again in step 2 since the domain names match (and DocuSign would create session cookies for the login).
Is there any way/process that we can follow which would allow us to not have to do this awkward double login?
thanks in advance!!!
First Login is the OAUTH login in which user is giving your IntegratorKey (Client_Id) access to call DS ESign APIs and impersonate user on the user's behalf. Using this flow you will never get access to bypass DS Weblogin page to access the page hosted by DocuSign like the one which you have - https://appdemo.docusign.com/documents/details/c921ac4b-fdae-48a9-a70e-5d8a4e3e0089. If you want to give access to the user to edit the templates using API then you need to use below API call with the OAUTH Access token:
POST /v2/accounts/{accountId}/templates/{templateId}/views/edit
Documentation for the same is available at:
TemplateViews: createEdit
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.