I want to use Google Pay in a Firebase web app. The user signs in to a Google account in the app. I have tested the example code from Google Developers for this. It seems to work fine.
Except when I sign out from the Firebase app. Then the Google Pay code still seems to work. Obviously now using the account I have signed in to Google Chrome with.
So I do not know for sure which user Google Pay sees. I can test a bit, but I need to be sure. How is this supposed to work? Where is it documented?
It doesn't matter how the web application is hosted (Firebase or otherwise), Google Pay will launch in the context of the currently logged in Google user.
One way to verify is to visit https://pay.google.com/. It will show you payment details of the currently logged in user.
EDIT: Responding with clarifications (apologies for the length)
I want to use Google Pay in a Firebase web app.
Assume that I in this case is you the developer.
Except when I sign out from the Firebase app.
Assume that I in this case is you the user, signing out of the web application and not the Firebase console.
The user signs in to a Google account in the app.
The web app uses a Google identity to authenticate the user - correct?
It seems to work fine.
Except when I sign out from the Firebase app. Then the Google Pay code still seems to work.
Is the scenario that you are describing the following?
User is not logged into Google
User signs into web app with Google identity and is presented to Google login screen
User clicks on Google Pay button from within the app - everything works as expected
User signs out of the web app
User returns to the web app after signing out of the web app?
User clicks on Google Pay button from within the web app as an anonymous user (from the web application's perspective) - which brings up the Google user's payment details and this is not what you expected
If so, then:
Step 2: two things happen
Google sets a cookie to maintain keep track of the user's identity
Google returns an auth token to your app, your app will generally use this to maintain session state using the auth token
Step 3: using the cookie that was set in step 2, Google present relevant payment methods
Step 4: signing out of the web application should clean up the user's web application session state, but it wouldn't sign the user out of Google
Step 6: because the Google cookie is still present, Google Pay continues to present the user's payment details
From my perspective, this is working as intended.
The web application's session is separate from the Google session, think of it as the web application using Google to bootstrap its own session. Once bootstrapped, they are disconnected from one another.
The user could sign out of Google after bootstrapping and that shouldn't affect the web application. If the user logs into Google as different user, they will receive a different Google Pay profile, and they should be able to fulfill payment with the second Google identity's details despite signing into the web application as the first Google identity.
You should be able to verify this behavior by visiting https://pay.google.com/ after signing out of the web app, then again after signing out of Google, and then signing in again with a different identity.
Related
I want to develop a Web App which runs on Firebase where I log in (once) using the providing google sign in.
The App should use the google APIs to display a variety of informations (email, some special calendars etc).
The idea is to have this Web App run on my tablet 24/7 and never touch it but according to this the authentication token will expire after 24 hours which means I need to login every 24 hours.
What is the best way to have a "persistent" login which only expires when the device (or browser) is shut down?
You're looking at documentation for IoT core. Unless you're using IoT core, that documentation won't apply to you
In regular web apps that use the Firebase JavaScript/Web SDK, the ID tokens is automatically refreshed every hour, and credentials are persisted by the SDK and restored when the app restarts.
In practice this means that the user can sign in once, and stay signed in until you either sign them out explicitly, or until a compelling event forces them to reauthenticate (something like their password being changed, or you disabling their account). Unless something like that happens, you can always get the currently signed in user by using an auth state listener.
I'm creating a firebase application that uses user authentication, in addition to an express server for video calling with Twilio. Right now, I'm not quite sure how to test signing in multiple users to my application, as when I open different tabs to localhost:3000 both windows redirect to the same location whenever I change the route (using react-router-dom). Therefore, when I try to sign in on a different tab, all other tabs will redirect to the sign in page instead of remaining on the home dashboard.
Could this be a problem with how I'm handling users in Firebase, or how I'm testing with express?
Any help is appreciated.
Firebase Authentication doesn't really support signing in multiple users into a single app instance. That sign-in is shared globally among all tabs loaded with the same site. If you try to sign in a new user, the old one will be immediately and forcefully signed out. This is true on all client app platforms, including iOS and Android.
If you want to test two users signed into your site at the same time, try two different browsers, or use two different Chrome profiles, so that the per-user storage is different for each browser window.
I'm working on a Google home application using an external API. I need the current user to be logged in and linked with the external API (access/refresh token provided by the external API).
My approach:
Setting up a firebase application
The google home app lives within the functions folder.
I would set up a page where the user would first sign in with his Google account using firebase.auth(), then his external API account (using the external API Oauth).
I would then create an entry in the firebase database to store, for each user, an access/refresh token provided by the external API.
This is where I'm a little confused and stuck. I've managed to setup the sign-in page (Google sign-in, then External API Sign-in) and store it the the firebase database (/users/{google_uid}).
Now that it's in the database, how do I set up the authentification in the Google home app?
Thank you!
First, you need to have a project in console.developers.google.com and activate the Google Actions API in your project. Then, you should follow these steps:
Whitelist the following redirect URI in your API:
https://oauth-redirect.googleusercontent.com/r/
In your API.AI project go to Integrations and enable the Actions on
Google Card.
In the setting of the Actions on Google, place your project ID and
select Sign in required for the welcome intent and any other
intent the user needs credentials.
Below, you will find the OAuth2 fields, like clientID, client
secret, authorization URL and token URL. Fulfill it with the OAuth2
information of your API and Authorize the application.
After you authorize, you can Preview the application and it will be available in your Google Home device, and when you invoke for the first time, it will provide a card in your Google Home app to do the linking. If you don`t have a device, there is a Web Simulator where you can test your Action.
For more information access the actions on google documentation.
There are a few issues with how you're thinking about account linking with Actions On Google and Google Home. Google Home doesn't give you direct access to the Google account - instead, it acts like a web browser and the account linking process requires you to issue an OAuth2 token to the Home "browser" for it to use in the future.
If you have control over the external API, and it issues OAuth2 tokens (which it sounds like it does), you can skip the Firebase portion completely. You just need to configure API.AI with the OAuth2 information for this external service - the client ID and secret, the URL for the login page and for the token exchange page, etc. In this case, your webhooks will be called providing the OAUth2 access token that you should pass on to the external API when you're calling it. The details are in the Actions for Google documentation Account Linking documentation.
If you do not have control over this API, you may need to provide a basic implementation of an OAuth2 server that can hand out auth tokens (either ones you create or ones that can be used to get the auth tokens from the external API). Your webhooks will then be called with these OAuth tokens, and you should use the token to find the token to use to access the external API. You have some options to implement this, and these options are discussed at OAuth2 Account Linking Overview in the Actions for Google docs.
I have a Web API and an Azure Web App that access the same database. This database has all user information. I'm using ASP.NET Identity for user management. I'm having an issue where when a user is created by the web app the Web API requires a restart, or at least a relatively long while before the user becomes authenticated by it. This, of course, is entirely impractical. How can I update the environment immediately on the Web API so that the user can access their resources?
UPDATE 3:
Turns out it WAS authenticating with the API, but I didn't hold the correct claims because my user was not associated with a Google account. See Answer below.
Wow. Nevermind. We require Google accounts to sign on one kind of client, and we SHOULD require it on the web client, but I haven't set that up yet. If an account is set up without an associated Google account, AND that email has a Google account set up on the client then it will try to authenticate with those Google claims that don't exist in the DB. So while I CAN authenticate with that claim through the Google SSO, there are no claims set up in the DB, resulting in 401 errors. Authenticated, but unauthorized.
This means my auth filter is probably misconfigured because it should not authenticate with Google if my account does not have an associated Google account, no matter what my client requests. It also means that I need to refactor my SPA on my Web App that statically calls for Google authentication with the API.
I am using facebook/twitter logged in user to authenticate my web api. i followed this
Okay that was most likely what I what. But my view page will be differently hosted. That is user will be logging in with a different page and they will send an ajax request get values from api controller.
I would authorize the web api only to user who is logged in.
If by "differently hosted" you mean on separate domains, then you won't be able to share a cookie between the two. If you mean that the client is a iOS app or Windows Phone app running on a device, the general pattern is to use a "Browser Control" and build a little UI as part of your API site. You can show your users this UI in the browser control and then scrape the token out. If you use Azure ACS, this is much easier with the "javascriptnotify" protocol that enables the token to be pushed out of the browser control.
The best article I've seen on this is http://www.cloudidentity.com/blog/2012/04/04/authenticating-users-from-passive-ips-in-rich-client-apps-via-acs-2