We are prototyping in dialogflow which is going well but I have what is more of a strategic question. Our app will interact with APIs in a third party system that requires user/password credentials, I am wondering if anyone can recommend an appropriate approach.
For example when I start the app in Google Assistant it knows who I am from my google account, this account however has no authorization for the target system - it needs an ID / password. I can prompt the user for these and they can type/say the values with which we can connect but this prompts more questions:
Is this secure? Clearly speaking my password isn't a great plan.
If this approach is reasonable is there a way to save my credentials within the app so that I don't have to enter them next time?
Are there other approaches to remote authentication you'd recommend? I have searched around but so far without any success.
Any tips would be much appreciated.
Chris.
Google provides build in authentication options for Google Assistant. Have a look at the documentation. If you wish to connect your Google Assistant app to your own login you want to have a look at the 0Auth or Google Sign-in + OAuth options. Depending on your requirements, one might be a better fit.
Accountlinking is a build in solution, if you implement this you will have done it in a secure way and it is integrated with the users Google Account, so when they come back into your app they won't have to enter any credentials again.
Related
I have in the past done a hand rolled app that stores a user token on client side $window.sessionStorage.
I have since then realized this is not safe. I am now looking for the most safe, standard way to secure an app that uses a node/express backend api that I will make, and also uses a front end that makes requests to this api such as angular for web or a native mobile app. Plus, whenever I would close the browser, I would have to re-log in because the $window's session storage was wiped out.
From what I've researched thus far, one of the safest ways to date if you're going to handroll it is to store a jwt in an http only secure cookie.
However, I'd kind of like to use a service that already exists, such as oAuth. Couple questions:
1) How safe is oAuth in terms of keeping ownershp of your userbase? What if 3 years from now oAuth just suddenly or slowly dies out? Aren't all my users technically stored on their server? How would I keep my users native to my app?
2) If I'm going to be creating a startup app in the same realm as snapchat, twitter, tumblr, etc... would it be generally recommended to use a service like oAuth to handle my authentication? Of course the future is unknown, but assuming the best, that my app would reach millions of users, would using a service like oAuth still be a smart choice? It seems like once you start using oAuth, there's never any going back to storing your users in your own database a year or two down the road.
Thanks
OAuth is an open standard for authorization.
Maybe you're thinking about Auth0. There are a lot of services that can handle user authorization for you, including Auth0, Stormpath, Apigee, UserApp, AuthRocket or Amazon Cognito. Whichever you choose, make sure that you can get the database from them in case you want to stop using their service. Not everyone explicitly offers an easy way to leave them but if that's important for you then make sure who suits your needs and who doesn't, and base your decision on that.
As for OAuth, see the https://en.wikipedia.org/wiki/OAuth article.
There's a huge list of OAuth providers on Wikipedia but those are services like Twitter, Google or Facebook. In a way you can use one of those services to manage all your logins but as soon as they see you as their competition, you're in trouble. I've heard stories like that.
Some interesting read on the subject:
The dangers of OAuth/Social Login
Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services
OpenID Vulnerability report: Data confusion
Social Login Setups – The Good, the Bad and the Ugly
I ran Google Cloud Security Scanner against my Google App Engine app. I asked it to authenticate against a "Non-Google Account" -- in other words, user-name/password fields in my webapp. However, I get back the message "Could not sign in using the provided username and password" each time.
(I tried it several times, specifying different user-agents and credentials and against two variants of my login page; and of course confirming that the credentials work when typed in manually. I have the necessary Editor-level permissions on the Google Cloud project.)
What do I need to do to get the Scanner to authenticate?
Here's what the docs say about Non-Google account authentication:
Note that support for login forms is still in development, and may not
work out-of-the-box with your system. If you have confirmed your test
account is able to login manually, but not in Cloud Security Scanner,
use the feedback option within the tools to request support.
One possible workaround is to create a simplified alternative login form for the purposes of using the scanner if it's unable to work with the current one.
I am creating a web app and I have implemented authentication using Facebook, Google. Now I want to authenticate using weChat. I understand I need to use "passport-wechat-auth" but for that I need to create wechat account and that throws me failure each time. SO if anyone have better idea to implement it will be very helpful.
Basically you must have a official wechat account to implement. For authentication as like FB etc, you an use WeChat-oauth npm module to do it.
In-Case if you don't have a actual official account. You can use sandbox account for development.Wechat Sandbox
I'm trying to create a login system with Node as the backend/web service for the app, also with an iOS app. I'm trying to use Amazon Cognito to do this, but I can't figure out how to register/authenticate users from either end. The only tutorials I've been able to find use Facebook login, which don't help me.
Edit: I have unauthenticated identities working somewhat, but I'm still clueless as to the authenticated developer identities.
While I understand you are looking specifically for a Node sample, we do have a full end-to-end sample with a Java backend and iOS and Android clients.
The clients also handle transition from unauthenticated to authenticated, linking multiple logins with your developer identity and more. Hopefully this will help fill the gaps you have. If not, please let us know what we can do to improve.
With the recent release of Azure AD, we would like to use Azure AD for our web application authentication, but we do not want to use SSO. We do not want users to be redirected to the Microsoft Account login screen, and then come back. We want to supply them with the login credential screen where we capture their username and password, and then we want to programatically do the authentication against Azure AD, and get back the claims identity.
The problem I have is that I cannot see how I can do that using the Graph API, and all the examples that look like it might work, only works on the previous [0.8] release. There is such a mix of examples that is supposed to work, but they don't simply because of the new release.
Can anyone tell me if this is even possible, and maybe point me in the direction of how to do it please.
I do not want to use ACS.
What you are asking for is not technically possible with Azure Active Directory today. That scenario could possibly be supported in the future, so check back from time to time.
We really encourage developers to rely on the in browser sign in experience. The reason is that because the browser allows the server to define the experience, it allows for much greater flexibility with respect to the kinds of credentials that can be employed. For instance, if you code your app to use only username and password, then it may need to be updated in order to take advantage of two factor authentication. If you rely on the browser based experience then your app can be totally agnostic to whether 2FA is being employed, or any other kind of authentication dance.
We recognize that there are some scenarios where this is not ideal or even practical and are looking at solutions to those scenarios that may be supported in the future.