What is the flow with Yodlee MFA account? Do I need add MFA request to every refresh action or only once at the first time login to provider?
MFA needs to be passed during every refresh if the site is MFA. Follow the Add and Refresh flow diagram present on on portal. Also, you should try using Fastlink 2.0 - a great UI to add, edit user accounts.
Related
I recently completed an OpenId Connect integration of OneLogin to our asp.net core webapp.
I implemented the "authentication flow" and used the OneLogin OIDC .net sample app as a basis: https://github.com/onelogin/openid-connect-dotnet-core-sample
In our development and staging environments the OIDC integration works as expected, but in our production environment we see an oddity:
Once the user has completed their login and MFA challenge (we use Duo for the MFA challenge) the user is redirected back to perform their MFA challenge for a second time. After they've been through the MFA challenge for a second time, the flow redirects back to our app as expected.
Analysing the http requests it's clear that this looping back to the beginning of the MFA challenge is happening prior to the .net core "signin-oidc" callback in our web app. It all appears to be on the OneLogin side of things.
Specifically, after the MFA challenge hass succeeded a request is made like so:
GET https://ourdomain.onelogin.com/trust/openid-connect/v2?client_id=etc
The result of the request is a redirect back to the start of the MFA challenge i.e.
https://ourdomain.onelogin.com/login2/?return=
I'd expect the user to only have to complete the MFA challenge once, instead of the twice that we're seeing.
I'm struggling to diagnose the issue as it doesn't appear to be related to my code. Any ideas?
After going through OneLogin support this turned out to be a bug on their side. A workaround was to change the configuration option which controls how often to show the MFA. (It was previously set to always show the MFA challenge)
We have a website where users authenticate themselves using AWS Cognito. That has been implemented using Next Auth with the Cognito provider based of their example code. That is working fine. However, whenever a new potential lead (customer) fills out a particular form we ship that information off to an external API. That API is connected to the same Cognito client and user pool in AWS, and it creates a new user and performs some operations. In the response of this API we receive the newly created user's access token, refresh token and identity token. The reasoning behind this is that whenever a new lead is created they automatically gets assigned a user and we log them in behind the scenes. It is far from an ideal solution, I know, but our assignments doesn't allow for rethinking and rewriting the current setup.
My questions is how we should implement such a custom login flow. We want to validate the tokens in the API response and create a session using those tokens, much as a regular login flow would do.
I've included this simplified chart trying to explain the process. See link:
Login flow chart
For anyone encountering a similar issue, this is how we solved it: After receiving the id_token from the external service we do a router.push(...) (next/router) to our own authorization callback API endpoint with the id_token. In our case, it became:
/api/auth/callback/cognito?id_token={ID_TOKEN}
I'm using Authorization Code Grant to authenticate from my cloud app to DocuSign. I followed the excellent directions provided by DocuSign. When I authenticate the user I get the DocuSign Login screen and consent dialog. If I then authenticate again somehow DocuSign decides the user hasn't changed and doesn't pop up the login and consent dialog. Usually this is acceptable because it is indeed the same user.
However, if I logout of my application and then (before closing browser) relog in to my application as a different user then I am expecting that when I request to authenticate to DocuSign that the login and consent will come up. That isn't happening and DocuSign returns user information for the original user.
What mechanism is DocuSign using to determine that the user hasn't changed? Is it browser cache? More importantly is there a way I can disable that when I am starting the authorization code grant so that I can authenticate the second user?
Please add query parameter &prompt=login in your initial url. This will show login page everytime.
I need to login users via Instagram for my mobile application so I can make calls to Instagram API and get some information from the Instagram. Simply, my application will ask user to authorize Instagram access and able to get access token for API calls. Application should not ask user to login again once the user is authorized. I already setup my Instagram client-app to implement server-side authentication flow.
My challenge is I want to do this on by using AWS mobile services. I already setup custom authentication from MobileHub and came to point where I need to define my custom authentication flow (in this case it is Instagram authentication flow). Under AWS Cognito app when I go to Triggers tab, I see different options for defining lambda functions associated with my authentication (such as pre/post auth or define / create / verify auth challenge). I am not sure how to align Instagram Authentication flow with these functions. Or should I use something else. Also I am not clear how does AWS Cognito manages authentication flow: I don't want my users to go through authorization process every time they start my application. I believe AWS Cognito link users from my custom flow to some Cognito identity and able to authenticate when they use my application. I really appreciate any suggestions, or even code sample (if available).
Check this Document for Cognito Identity. Instagram is not there by default. So you have to use External Identity Provider, most probably using Open ID Connect Providers.
We want to allow our users to retrieve a set of temporary CLI credentials for a given AWS role by signing in to OneLogin with password and MFA. We have a working solution, but it requires the user to fully re-authenticate to OneLogin (including MFA) every 60 minutes as the AWS temporary credentials expire. I think that won't fly - our users are accustomed to permanent API credentials tied to a real IAM user.
Ideally, we'd like to allow users to authenticate once a day, securely cache the resulting SAML assertion, and use that to transparently refresh the AWS API credentials as needed. I'm thinking of something like aws-keychain that would use the local OS credential store to remember the SAML assertion, and only prompt the user for input when their OneLogin session has timed out.
This almost works as-is. The catch is that the SAML assertion returned by OneLogin's saml_assertion and verify_factor endpoints sets a three-minute deadline on the Subject and Conditions fields.
Is there a way to do what we want, or are we trying to route around a core SAML principle?
The accepted answer here is no longer true. It is now possible to authenticate the user and verify MFA once at the start of a session and then have the session refreshed on an hourly basis without having to enter further MFA tokens.
To do this you must use the --loop parameter of the CLI tool and have a corresponding App Policy in OneLogin that enables the "Skip if OTP received within last X minutes" setting.
https://developers.onelogin.com/api-docs/1/samples/aws-cli
We're in the process of officially adding an option to in our official CLI tool to re-use the user credentials similarly to what you're describing.
Essentially our CLI tool has an option to reuse the user/pass in the background to continuously refresh the access info in a user profile so while the user will provide credentials once, the access info will get updated before it expires.
But unfortunately, at least at this time, there's no way to get around the MFA part if the application policy requires MFA. It'll need that MFA to refresh the credentials.
If you have to have MFA, you can always use the OneLogin MFA APIs to bake in an MFA flow into the tool...
Check it out here: https://github.com/onelogin/onelogin-aws-cli-assume-role/pull/5