How do I force refresh of a yodlee site_account? - yodlee

Using the Yodlee API, if I have a successfully connected site_account, and then something changes (say the user updates the answers to their MFA questions) causing refresh to give Yodlee an error, how do I force it to refresh so that I can retry entering MFA information? Using startSiteRefresh I can't get it to force refresh, even with forceRefresh on RefreshParameters set to True. All I get back is SiteRefreshStatus=None with the previous error code, and it doesn't let me ask for new mfa questions at all.

To update the credentials you should use updateSiteAccountCredentials.
But to refresh you should be using startSiteRefresh and check for refresh mode
(siteRefreshInfo.getSiteRefreshMode()) if the refresh mode is MFA_REFRESH_MODE then you should start the MFA flow.

Based on the error, if you want to change the values like username, password, Q&A for MFA, you can use the updateCredentialsForItem call to edit the item. You can then refresh the account.
More details on this page.

You are correct, for site the API is different.
First you would need to call getSiteAccountCredentials or getSiteAccountMfaQuestionsAndAnswers to get login form or MFA QnA as needed, and then updateSiteAccountCredentials.
If the changes worked, refresh would be triggered.

Related

AWS Amplify/Cognito- a way to set TOTP MFA on first time user login only

I'm setting up an authentication where MFA is not optional, which means from the very first login attempt after registration, the user will be asked to set up MFA (in this case I will be using Time Based One Time Passcode, or TOPT). For this, I can see that following steps would be reasonable:
1)Get user information via the login form - Auth.signUp()
2)Determine from the user data retrieved in step 1) whether TOPT-based MFA is set for the user already. If not, go to step 3) or else step 4)
3)If TOPT is not set, redirect to a form where a QRCode will be generated in order to set up this MFA feature. After verifying the code, log the user in.
4)If TOPT is set, ask for the passcode. After verifying, log the user in.
My dilemma: It seems I cannot get the information in Step 2), i.e, whether TOPT-based MFA is set for the user already without the user already being authenticated. The flag challengeName retrieved in the payload via Auth.signUp() in step 1) only gives me info on whether MFA is enabled or not ('MFA_SETUP'), and not whether TOTP-based MFA has been set up already. For that, the method Auth.getPreferredMFA() is what would do the trick, but it only works if the user object being passed to it represents an authenticated (or already logged in) user. Is there a way to determine if TOTP MFA is set up for a user trying to log in (but not logged in yet)?
Also, any other solutions to tackle this problem would be welcome. There must be somebody out there who has run into the same scenario I have, where MFA is mandatory from the first log in itself.
I am facing the same issue. If the MFA is required, I open up a modal to get QR code displayed and setup the mfa for the user.
code: "NotAuthorizedException"
message: "Invalid session for the user."
name: "NotAuthorizedException"
But getting this error because the user hasn't logged in and created any access token yet.
My idea of solving this is actually logging in the user but making their permissions to not go beyond the SetupMFA screen so they only gain some permissions when they have completed the setup.
Have you made any progress yourself? I'd like to hear any solutions.

Using FastLink for Account Refresh and Edit

We are trying to use Fastlink to provide instant refresh and account edit functions. This has not been successful as we keep getting "Problem updating account" FastLink UI.
We do not want to use the ProviderAccount PUT API to trigger refresh as we want to stay away from providing login/MFA UI. FastLink has been very helpful in providing the account add function and we really want to leverage it for all the account related functions.
Please use the following sample values in extraParams for refreshing or updating account.
Refresh Account:
String extraParams="flow=refresh&siteAccountId=10139794&callback=https://www.google.co.in";
Update Account:String extraParams = "flow=edit&siteAccountId=10139794&callback=https://www.google.co.in";
Please pass the value of providerAccountId for siteAccountId.

Yodlee refresh on an already-active MFA account

Re: Yodlee site-based API
a) I know that when adding an MFA account you are supposed to trigger /jsonsdk/Refresh/startSiteRefresh. But if an account is already added and already active, and I want to trigger a manual refresh to get new data, is /jsonsdk/Refresh/startSiteRefresh the correct API to use?
b) When I do use /jsonsdk/Refresh/startSiteRefresh for a manual refresh, I do not want to trigger the whole MFA flow, I simply want to pull new data if possible. So which refreshMode do I specify "MFA" or "NORMAL"?
I ask this, because I used "MFA" mode and it failed with a 522 (timeout) error due to a new security question. But when Yodlee runs the nightly refresh, the same condition will result in a 506 or 518; not a 522. Maybe I am supposed to specify "NORMAL" even for "MFA" accounts for a manual refresh?
You need not pass the refresh mode in the startSiteRefresh API. When you call this API for a siteAccountID the response will tell you if the MFA is required or not. Below fields can be used from the response.
"siteRefreshMode":{
"refreshModeId":1,
"refreshMode":"MFA"
}
Depending on the refreshMode you can follow the MFA flow or Normal flow.
When you trigger this API you will have to flow the complete flow to get the latest data or else the refresh will fail and data will not be updated.
Refer - startSiteRefresh for the API and Refresh Flow for refreshing an account.
I ask this, because I used "MFA" mode and it failed with a 522 (timeout) error due to a new security question. But when Yodlee runs the nightly refresh, the same condition will result in a 506 or 518; not a 522
This is because in case of manual refresh you as a user is not answering the question asked at the end site and hence our server identifies it as no response from the user and hence 522 error code. When it's automatic refresh from Yodlee's end and a new question is encountered the error code is 518.

Yodlee Site cannot be refresh

I'm trying to test the MFA in Yodlee with the dummy account DagBankTokenFMPA. I let the MFA timed out and now everytime, I try to refresh I got the same error :
{"siteRefreshStatus":{"siteRefreshStatusId":10,"siteRefreshStatus":"SITE_CANNOT_BE_REFRESHED"},"siteRefreshMode":{"refreshModeId":1,"refreshMode":"MFA"},"updateInitTime":0,"nextUpdate":2047149073,"code":522,"suggestedFlowReason":{"suggestedFlowReasonId":2,"suggestedFlowReason":"ACCOUNT_IN_ERROR"},"suggestedFlow":{"suggestedFlowId":3,"suggestedFlow":"EDIT"},"itemRefreshInfo":[{"memItemId":10088102,"itemSuggestedFlow":{"suggestedFlowId":3,"suggestedFlow":"EDIT"},"itemSuggestedFlowReason":{"suggestedFlowReasonId":2,"suggestedFlowReason":"ACCOUNT_IN_ERROR"},"errorCode":522,"retryCount":1}],"noOfRetry":1,"isMFAInputRequired":true}
How can I prevent that ? Do I need to stop the refresh with stopRefresh and start over ?
In this case you need to call updateSiteAccountCredentials API and just pass the details again, this will trigger a refresh and then you need to call getMFAResponseForSite to see what MFA information is required by the bank.
To add more, it seems like you are mixing two sets of APIs here. We recommend to either use container based APIs or Site Based set of APIs, in conjunction with Core APIs which are common to both.

When is access_type = Online appropriate? :OAuth2 - Google API

When requesting OAuth credentials, I can specify the access_type to be Offline or Online.
Opting for the Online access type forces the users to approve access to my app each time they login. Why is that? Hasn't the user already approved my app?
Update #1:
I have my approval_prompt set to 'auto'.
If I just log out of Google without deleting any cookies, it doesn't prompt me again. But deleting the cookies brings back the grant screen.
Update #2:
It works fine through the OAuth Playground. http://code.google.com/oauthplayground/
Using OAuth 2.0 for Web Server Applications
https://developers.google.com/accounts/docs/OAuth2WebServer
Update #3:
Relevant code snippets
Helper method to generate OAuth URL
def build_auth_uri
return #client.authorization.authorization_uri(
:access_type => :online,
:approval_prompt => :auto
).to_s
end
Calling the Helper method in the View
Connect Me!
Generated OAuth URL on the webpage
https://accounts.google.com/o/oauth2/auth?access_type=online&approval_prompt=auto&redirect_uri=http://localhost:3000/gclient/gcallback&response_type=code
There is one other parameter that comes into play in these flows and I suspect you're running into it. It's the approval_prompt parameter.
When access_type=online you are also allowed to specify a value for approval_prompt. If it is set to approval_prompt=force, your user will always be prompted, even if they have already granted.
On the other hand, when access_type=offline, approval_prompt can only be set to approval_prompt=force, but to make up for this restriction you're also provided a refresh_token which you can use to refresh your access token.
Check the URL that your access_type=online is opening. Try setting approval_prompt=auto. The grant screen should only appear the first time.