With Firebase's Admin SDK, I want to allow a user to login (verify the user with my Firebase instance) without any JavaScript on the front end. Just an old fashioned POST, with the form data in the request body.
Then in node (server side) verify the email and password on the back-end, retrieve a token, update the user's session, pass back a cookie, etc. I've been digging around various examples and the Firebase Admin SDK docs but have not found an answer.
I can do it if I run the non-admin-SDK Firebase module, in node, but this seems like an odd approach to me, especially as I need the Admin SDK for some other things.
I could see why they want to force a "triangle" approach like say payment auths use.
Authorize with Firebase on the front end and pass a token to the back-end.
Not allowing the password to possibly be sent or stored on the node server unencrypted.
But I want to pass as little JS to the client as possible and I want my site (MPA) to be progressive (not need JS). It seems odd they would not address this in their docs. Other than in some explanation of how to write one's own validation or integrate with another.
If anyone can describe how this can be done or what the recommended approach is, I would be very happy.
Firebase's Admin SDKs are designed to be stateless, so don't have a concept of a current user. The recommended approach is what Firebase Authentication does, sign in on the client and pass an ID token with every request/connection to establish the identity of the user.
If you don't want to use Firebase's SDKs in your client-side application, you can call the REST API. I'm not sure if you can construct the right call with a FORM post though.
Also check:
Sign in with Firebase-Admin using node.js, the main answer is the recommend approach.
How to authenticate an user in firebase-admin in nodejs? shows how to sign in a user in Node.js with the regular/non-Admin SDK. This is probably closest to what you want to accomplish.
I have a web application setup to handle webhook requests from an Actions-on-Google/Dialogflow application using the Google Assistant. Users don't need to sign-in to a google account in order to use my web application and I'd prefer to keep it that way, so that users can sign in with any email address.
I also want my users to be able to interact with my application using the Google Assistant, and be able to access personal/contextual data via the assistant (i.e. when a speaker says, "what's on my shopping list", the web app needs to be able to know what my means).
Currently, I have this working by using my web app to issue a unique short code to my user (in the web app UI) and then with an intent on the Assistant where the speaker says "My code is 1-2-3-4" and then my web app can identify the user from then on (by saving the userId from the webhook request to whatever user got the short code 1234 and then using that userId to lookup the user on each subsequent request.)
My question is, is there a better way to do this? Ideally, in my web app, I'd like to have something like an "Authorize Google Assistant" button, which would then link the user's google account to their web-app account, so that the conversation on the Assistant is seamless.
Has anyone done this before?
Thanks
This is the perfect use case for Account Linking with the Google Assistant.
From your users' perspective, they will start to use your Action. If they're doing so through a speaker and they haven't linked the account yet, they'll be directed to a mobile device to do so. On a mobile device, they'll be redirected to a page on your website where they will been to authenticate themselves and authorize your server to let them in through the Assistant. Once they have done so, they won't need to log in again, the accounts will be linked, and they'll be able to use the voice Action without further obstruction.
From your perspective as a developer, you'll need to setup an OAuth2 server (I suggest the code flow). That login process I mentioned is the first step in the OAuth dance, and will end up with you issuing a code to Google. They will then exchange this code for an Auth Token (with a limited lifetime) and a Refresh Token (which does not expire). They will periodically use the Refresh Token to get new, valid, Auth Tokens for this user. When the user issues a voice command, the Auth Token will be passed as a field in the JSON to your fulfillment server, and you can use this to verify who the user is and that they are authorized to use your service.
I've asked a Google Dev Advocate for help as I'm struggling to implement Account Linking on my Google Actions app, he sent me a link to a documentation article I already had read and suggested I also consult Stackoverflow. Having already done the second suggestion too and having struggled to find the exact answers to my questions, I've deiced to link to the doc article here, add all my queries and send this back to the Dev Advocate in the hope to get more clarification, especially as a reminder that Documentation could be read by complete newbies on the topic and that nothing should be given for granted.
This is the article I am referring to https://developers.google.com/actions/identity/account-linking
My queries below:
What is the difference between implicit and authorization code flow. In the article "Authorization code" is chosen, why?
Although I have found on Stackoverflow where to get your Client ID and secret, don't you think it would be good to add a link in the article?
Authorization URL - this is something instead I haven't found a clear guide for. Some Stackoverflow tickets report 2 Google OAUth URLs can be used (For the Authorization URL, enter https://accounts.google.com/o/oauth2/v2/auth
For the Token URL, enter https://www.googleapis.com/oauth2/v4/token), but a recent change to google policy suggests
When implementing account linking using OAuth, you must own your OAuth endpoint
So I'm now extremely confused at what I should put in the Aiuthorization URL and Token URL - why isn't this documented in a more basic and clear way? I've also read it needs to be served over HTTPS, what if you're working on local and on a pet project which isn't commercial and you won't be able to pay for HTTPS?
What is Seamless Account Linking and why isn't this explained and documented?
If your app supports seamless account linking
Where should we whitelist this?
Whitelist the following redirect URI: https://oauth-redirect.googleusercontent.com/r/
What are your OAuth 2.0 client configuration details? Where can they be found?
In the expanded OAuth 2.0 form, fill out the fields with your OAuth 2.0 client configuration. When filling in scopes, ensure they are space delimited.
I don't see the Discovery tab on my Oneplus 3T Google App, where else can I find it?
Open the Google app and go to the Discover tab.
This is where I get stuck - as many other people on Stackoverflow I get "The account is not linked yet" error. Maybe resolving the issues above will resolve the Account Linking error?
Invoke your app. Since it's the first time invoking the app with your Google account, the Assistant notifies you that you must link your account.
In addition to those questions, I also have the following:
I would like to get access to the user calendar and user basic info so I've added profile, email and https://www.googleapis.com/auth/calendar could you confirm these are correct?
Thanks and please remember documentation should be for everyone!
Documentation is for all developers. However, keep in mind that some of the tasks might require you, as a developer, to learn more than you currently know. Coming to SO is one of the ways to do that, but there are many other avenues that supplement that.
Good original documentation does, however, help. Google's docs are currently just bad - they used to be terrible.
Update - Before we begin, let me answer a question you suggest, but don't actually ask.
Why do I need an OAuth server at all?
First of all - you don't.
Think of your service like a website and the Assistant as a browser. For lots of websites, they don't need to know who the user is in order to use the website. There are lots of things the website can do without a user account at all.
In some cases, it is useful to know that the user visiting your website has visited you before. Frequently, you'll use a cookie to do track users like this.
The Assistant has an equivalent to this, although it is slightly different. The Assistant sends an anonymous UserID with each message to you. This UserID is only for this user and for your Action - it isn't re-used for any other Action or any other user. So if you track it, you'll know when the user returns. Like cookies, users can reset or clear it, but for the most part, this is durable.
But sometimes, you might need a person to log in to an account on your website. This is what the OAuth server is meant to accomplish - give users a way to log into your Action. OAuth is a pretty standard way to let people log into services these days, although the intent is really to authorize a client to act on your behalf.
The latter is really what OAuth is doing in this case - your user is authorizing the Assistant to act on the user's behalf when talking to your Action.
(Update - There are now ways to avoid having to setup an OAuth server at all in some circumstances. See the update at the bottom of this answer.)
Now back to your questions
But... let's go over your questions.
What is the difference between implicit and authorization code flow.
These are two terms that are more carefully defined by the OAuth2 standard, but in short - both of them let a client (a remote server from yours - the Assistant in this case) to get a user to give certain rights on your server.
The Implicit flow is simpler, both in what you need to setup and what the two servers exchange, but assume that once you issue a token, it is indefinitely valid. This brings with it a slightly higher risk that someone can get this token and use it to impersonate the Assistant.
The Auth Code flow is more complex (although not a lot) and addresses the risks in several ways. One way is that some transactions are done server-to-server instead of including the client, and that those transactions include a shared secret. Another way is that the auth token has a limited lifetime, and therefore a limited window of exposure, but that there is a refresh token which can be used to get a new auth token.
In the article "Authorization code" is chosen, why?
Most likely because it is more secure for a minimal level of extra work. Most of the security issues it addresses, however, are most visible in more open environments such as browser and mobile - they're not as big a risk with the Assistant. However, for places that need to setup an auth server, going with the more secure route has benefits in other areas.
Most Google APIs use the Auth Code flow or variants of it. (Although most use it from the client side - not the server side. Which is what Account Linking for Actions requires.)
Although I have found on Stackoverflow where to get your Client ID and secret, don't you think it would be good to add a link in the article?
Well... except that SO answer is no longer valid. (And, apparently, was never intended to be valid.) As you noted in your next question, Google has clarified their policy that requires you own the OAuth endpoints you use for an Action. They have, furthermore, made technical changes that prevent you from using Google's endpoints. (And I've updated the answer to say so.)
While the "Configure cloud project" part is correct, and describes how you setup credentials to be used with the Calendar API, you cannot use Google's OAuth endpoints to do the auth for your own project.
So I'm now extremely confused at what I should put in the Authorization URL and Token URL - why isn't this documented in a more basic and clear way?
Because this is a point where they're making an assumption that isn't very clear in the documentation. It is suggested where they say "Step 1. Configure your server" that you have an OAuth server. If you have an OAuth server already, then you should know what your server's Authorization and Token URLs are.
If you don't, however, this does get further explained where they talk about determining what the endpoints will be for an OAuth service you're creating.
I've also read it needs to be served over HTTPS, what if you're working on local and on a pet project which isn't commercial and you won't be able to pay for HTTPS?
Yes, it has to be HTTPS. This is a requirement of OAuth, and good practice when you're sending tokens that can be used to do things authorized by a user. It sounds like you want to be able to issue API calls to a Google server, and if those tokens got out (or tokens that could be used to access the same resources), then your Google Account could be compromised.
You have a lot of options here for your local or pet project development. Just to list a few:
You can use Firebase Functions. For projects on a "pet" level, they're free. (And if your Action gets a little popular, Google Assistant will give you credits that should pay for a modest level of use.)
You can get SSL certificates for your server for free using Let's Encrypt.
Since your server has to have a public address, you can create a tunnel using ngrok, which also provides a public HTTPS address you can use. This probably isn't good once your project gets out of the "personal testing" stage, but is a good tool to start with.
There are other approaches, of course, but these are a few good tools that you can use depending on your needs.
What is Seamless Account Linking and why isn't this explained and documented?
It is. Except in the documentation they confuse things by also calling it "Streamlined Identity Flow".
On the Account Linking Overview page it says "For more information, see Streamlined Identity Flows about how to configure your OAuth server to support the seamless identity experiences on the Google Assistant."
This takes you to a page talking about how this flow builds on top of the other two identity flows and has some additional requirements, but should make the user's experience better.
However... don't worry so much about this. If you're just doing this for fun, the normal identity flows aren't that much of a burden. If you're doing this for a commercial product - get the normal flows working first.
Where should we whitelist this?
Whitelist the following redirect URI: https://oauth-redirect.googleusercontent.com/r/
This is one of the underlying concepts of OAuth - as part of the communication between the client server and your server, it will say to redirect to a particular URL when you're done authenticating the user and getting their permission to issue a token.
The OAuth spec requires you to compare that redirect URL to a URL that has already been setup for that client. It does not specify how you set that up. So Google is saying "When you setup the OAuth server for our client - here is the URL that we will ask you to redirect to."
Google can't answer where to whitelist this except "in your OAuth server". Most OAuth servers have a way to configure multiple clients, and this is one of the values you'll set for that client. (The ClientID and ClientSecret are other values, but Google lets you determine these values and tell it as part of the configuration for Account Linking in the Action Console. Which is your next question.)
What are your OAuth 2.0 client configuration details? Where can they be found?
Again, this depends on your OAuth server and your requirements for what you want to prompt the user when they try to login to your server. The ClientID and ClientSecret are two such parameters. The OAuth scopes that the Assistant should request access to are other parameters. But these are up to you - because it is your server they are trying to get access to.
I don't see the Discovery tab on my Oneplus 3T Google App, where else can I find it?
That documentation looks incorrect. I think that should say that you should open the Google Home app on your mobile device.
It is also possible that it does mean the Google app, in which case your phone may not support the Google Assistant as part of the Google app. You can download the Google Assistant separately, if necessary.
However - use the simulator to test initially. Although it requires a few manual steps, they are easy to follow and help you trace things.
This is where I get stuck - as many other people on Stackoverflow I get "The account is not linked yet" error. Maybe resolving the issues above will resolve the Account Linking error?
Well, your account isn't linked yet. {:
It sounds like you haven't set an auth server for your Action. Until you get an auth server working, the rest isn't going to work.
I would like to get access to the user calendar and user basic info so I've added profile, email and https://www.googleapis.com/auth/calendar could you confirm these are correct?
First of all, keep in mind that this whole process is to link the user's Assistant account to their account on your service. You may have information in their account (on your service) that you use to do things - such as access Google resources or access other things that you know about them.
This is not directly a way that you gain access to the Google account that they're using to talk to the Assistant.
In order to get a user's permission to access their resources on Google's servers, you'll need to get them to authorize your server permission to access that. That is done using OAuth, again, but this time you're the client. User's will need to go to your server, you'll redirect them to Google's server to authorize you, and they'll be redirected back to your server with codes that you will need to store. This is all done outside of the Assistant and it's Account Linking system.
That said, for what you want, profile and email are fairly normal scopes to request. The Calendar API Documentation confirms that the https://www.googleapis.com/auth/calendar scope is what you need to access that API. (Keep in mind that this URL is not one that you'd use in a browser or that you'd go to to access anything - it is a uniquely identifying name only.)
Update to reflect API Changes. Since this answer was originally written, Google has introduced Google Sign In for Assistant, which lets you avoid having to setup your own OAuth server when you are willing to tie operations to the same Google account they use on the Assistant. If the user permits, you can get simple user profile information this way, and you can then leverage this to get access to other APIs (again, with the user's permission). See this SO answer that discusses how to use this to access Google's other APIs.
Thanks and please remember documentation should be for everyone!
From my conversation with Google's Assistant team, they are looking to make documentation easier, and hopefully they will take many of your suggestions to heart. I hope these clarifications have helped you (and anyone else who gets here with similar problems.)
I'm trying to add Azure Mobile Service authentications to my WinRT app. I got everything working and I can sign in with all the 4 social media accounts(Facebook, Twitter, Google and Microsoft Account). But when I close the app and restart it, I have to write my user name and password even if I check the Remember Me button on either one of the options. Let say I logged in with my Facebook account, what I want to achive is, when I restart the app and click Login with Facebook, it shouldn't ask my username and password but automatically authenticate me. The remember me button seems to not working. Is there a way to achive this?
Thank you for the answers.
Edit: I'm using C#/XAML for my my app.
The following blog post covers caching the user's identity. http://www.thejoyofcode.com/Setting_the_auth_token_in_the_Mobile_Services_client_and_caching_the_user_rsquo_s_identity_Day_10_.aspx
According to this page: http://www.windowsazure.com/en-us/develop/mobile/tutorials/get-started-with-users-dotnet/
Note
... This method is easy to configure and supports multiple providers. However, this method also requires users to log-in every time your app starts. To instead use Live Connect to provide a single sign-on experience in your Windows Store app, see the topic Single sign-on for Windows Store apps by using Live Connect.
I'm trying to use Instapaper's Simple API (http://www.instapaper.com/api/simple).
The API terms of use (http://www.instapaper.com/api/terms) says apps should not store user id and password, and I don't want to store them either. However, it seems that the only way to add a link to a user's Instapaper via simple API is to store the username/password (if the user does have a password).
Am I missing something?
The API terms of use state that:
Apps must not store users’ passwords. Passwords may only be collected for the xAuth token acquisition and must be discarded afterward.
Only the full API uses xAuth tokens. The above sentence doesn't apply to the simple API, since it uses Basic HTTP Authentication.
You still "must make reasonable efforts to prevent passwords from being compromised, and must not disclose passwords to any other services or individuals".
If you are using a native Mac application (like Apple’s Mail client or a third-party mail client like Airmail) there isn’t an easy way to save a link to Instapaper without first opening the link in a browser and then using one of Instapaper’s browser extensions to actually save the article.
One workaround that I’ve found to expedite this task is to write a service for OS X which uses Instapaper’s API to save links.
In order to write your own service, first open Apple’s Automator application and create a new Service. Then, drag the Run Shell Script action into the application’s main workflow area.
Make sure the service receives no input, can be used by any application, and that the shell script is set to run python.