I am using the Plaid Link javascript library but I am running into an issue. I want to be able to use both the Auth and Connect products but the Link modal only allows me to show either Auth or Connect but not both. The documentation says to use Auth and then upgrade my token to use Connect. Which is fine I can do that. However the Auth modal will not show any credit only institutions like AmEx. Since I want both to allow for Stripe integration and for pulling in all of a user's transactional data across all institutions, what's the best way to do this?
Currently I am considering showing the different modals in two different flows (add a bank account vs add a transaction history account) but that is not very good UX. Also the IDs assigned by Plaid will be different and have different access tokens so deduping is a nightmare.
Or writing a custom modal that will use the Auth product for institutions with bank accounts (Chase) and the Connect product for credit only institutions (AmEx) but that will likely be a lot of work.
You'll only be able to use the Plaid Link + Stripe ACH integration for institutions that support Auth. I'd recommend initializing Link with Auth as the product and then upgrading to Connect once you have exchanged the Link public token for a Plaid API access token.
To answer the UX question you brought up - you can actually bypass using Link's standard "institution select" view and instead display your own list (you can use the /institutions API endpoints to pull information about supported institutions) using Link's custom integration.
That way, you can show your users a single list of supported institutions. If you initialize Link twice (once with Auth and once with Connect) you can jump directly to the Auth-initialized Link or Connect-initialized Link depending on the user's institution.
Related
I have API backend and it will be consumed by different consumers like our own company website and even other website can use our API with certain quota/limitation and for this scope management we will be using express-gateway(eg), however this is not the only reason I am using express-gateway(eg). Now coming to my problem/miss-understanding, for our own website we can create api-key and user credentials using eg command. But for the other user who wishes to use our api, I don’t want them to contact me for this integration, rather they should be able to create a user credentials and API key themselves using some facility (let us call it key management) provided by us. Here I am stuck how to give a web platform or any other mechanism where a user can create account and then create api-key for their own website. I was thinking to extend the express-gateway app itself and create page where a website owner can fill the form with various input field that will serve as parameter for eg command and I can trigger eg command in node console and create credentials and save it in redis database and then fetch those information to show it to user as their use rid and api-key. But I want to know the best way how others are doing, like how google, twitter and many more are allowing to create api-key, delete key and regenerate the api-key on compromise. Some suggestion would be to use third party tool to manage user-credentials, I will have little inertia to accept that, even if I do so how will I hook those third-party solution to my express-gateway.
In general, API gateways and authentication servers are independent, or at least loosely-coupled. The typical workflow is:
A user browses to the Create Account page for a service.
The user creates an account with the authentication server
The user makes a request through the API gateway
The API gateway checks with the authentication server whether the operation is allowed, discarding it if the user is not authorized to perform the requested action
The API gateway dispatches the request to the appropriate server
The receiving server checks whether the user is permitted to perform the action (in case the API gateway has been compromised)
Express Gateway includes its own authentication server for convenience, but the steps are basically the same. The difference is that one uses the Express Gateway Admin API to create the user and credentials rather than going to a different server.
Note that Express Gateway and its default account database (reddis) are not persistent out of the box.
Good morning,
We have to use two different approaches for customers' login:
Credentials Management API: https://developers.google.com/web/fundamentals/security/credential-management/
and ReCaptcha.
Do you have an idea on how to make them work together? Recaptcha is designed to block seamlessly auto-login of users via API call, and this is what Credentials Management do (more or less).
I'm the product manager at Google for user authentication.
Recaptcha isn't designed to "block seamlessly auto-login of users via API call", it's designed to detect bots, irrespective of where a bot might use an API call or script a form interaction to authenticate.
I'd suggest trying to auto sign in all users, and only apply trigger a captcha on operations where you actually see or believe there is abuse from bots (e.g. transactions) and try to use "invisible" whenever possible to avoid user friction.
My goal is to create a single click registration / sign on for my site using social media that's painfree yet secured using oauth and SocialAuthenticationFilter.
Ideally you'd be able to login to the same account with either twitter / Facebook etc (without first connecting them to a user account).
An example I'm working from is the Spring Social Showcase found on git, it's fantastic but it still requires an intermediary 'sign up' step.
I can't figure out a way of making a secure account using only the info from Facebook login using aouth and I'd prefer it if a user didn't have to sign up and connect as per the example.
So, is there a secure way of doing this or am I misunderstanding something?
Thanks
Using OAuth / OIDC is the right way to go.
In order to automatically match the logins from different social login providers, you have to rely on the email address as the primary user identifier.
Once relying on the email address, you may automatically register new users inside your internal DB.
However users may want to change their email address. This may complicate the processes significantly, depending on what options you want to support.
I made a members-only site that uses Google oauth2 to authorise users. The site is built with the Laravel framework and Artdarek's oath library.
When the authorization callback comes from Google, I lookup the user record in the DB by email and proceed to the protected page if the record exists, otherwise to a register page.
The problem is some of our members use two Google accounts. One user registered via his primary account (e.ge. a#gmail.com). The next day he returned and mistakenly tried to login with b#gmail.com. Naturally the system showed him the registration page. From that time on each time he visits the site the authentication mechanism sees him using his second (unwanted) set of credentials.
To resolve this one case I instructed him to logout of all accounts (on both sides), clear cookies and start from scratch but this is not a practical solution for all users. In same cases even this measure does not seem to correct the problem.
How can I solve this case? What is the right way to request oauth authentication and get them back from the right account? Can I force Google to ask the user with which account to proceed?
Google will automatically ask the user which account they want on an oauth request if they enable the account chooser.
I have logged into my Google Apps and my Google account, so for me on an oauth request, I get the following prompt:
In order to do the same for your user, they have to click "Stay signed in", but of course this is not advisable for public computers.
Beyond the above, I'm afraid not much can be done. - if they logged in with a#gmail.com at that time, these are the credentials you will receive.
They way I solve this problem is to have a field where the customer can add additional emails, and select one that is primary. I will then inspect against these emails when a request comes in to avoid duplicate user accounts.
I'm building mobile applications using .NET. What I'm looking for is a way to manage user sessions and info using Azure Mobile Services. I've read a lot about the authentication in Azure Mobile Services, but this only authenticates a user via Facebook, Twitter, etc ... to access azure services.
I'm looking for user session management, i.e. register, login, logout. Be able to save and retrieve user info, i.e., save certain info against the user such as age for example. Also session management and caching, i.e. the user will remain logged on when the app is closed and re-opened. Also azure mobile services doesn't seem to provide a way to allow me to register users via email.
Basically, If anyone is familiar with Parse, I'm looking for having similar functionality in Azure. Can anyone help please ?
Thanks
Out of the box, Mobile Services provides easy authentication with social providers (Facebook, Twitter, etc) and Azure Active Directory. If you want to do registration via email, you'll have to create a custom auth system. This is going to be more complex than just flipping a switch and using Facebook auth, but totally doable and I can point you in the right direction. First, check out this post that will explain how you can create a registration / login system using custom API and the script backend. If you're using a .NET backend, you'll need to alter thing a bit (the samples are in JS) but it should be pretty easy to convert. The only piece that is really missing from that post is how to do email verification. To do this with Mobile Services, I would suggest the following.
Sign up for a SendGrid account (free in the Azure store)
From your script, after registering the user, generate a random alphanumeric string that is saved to their account / user record in the table.
Use the same string to create a URL which you can send to the user's email address (check out this tutorial for sending email via SendGrid and Mobile Services).
The link can either go to a different custom API or a web front end. When that endpoint is hit, it should update the user record to show that they have verified their email address.