we're using account linking with Google Sign-In, and store the user information in the Firebase auth database, similar to what is described here: https://developers.google.com/assistant/identity/google-sign-in
If a user later goes to their Google account settings and removes our action (i.e. revokes access), is there any way we can know that this happened, so that we can remove them from our Firebase auth database (plus remove any other data, as needed)?
I've searched far and wide but haven't found a clear answer to this anywhere, so any pointers and help much appreciated!
Take a look at registering for Cross Account Protection (RISC) notifications. This will let you register a webhook that will receive notifications in the event a user account has been compromised, if they remove authorization, etc.
Related
I have an interesting use case for you today.
My team and I are building a free, third party, calculator tool that enables users to calculate metrics using their store's data.
We are looking for ways to pull in the necessary data and perform the calculation to show users... so far the best we've come up with is asking the users to export a report from Shopify and upload it into our application.
Looking for a user experience similar to this:
User opens our tool, application is hosted on custom-domain.com
Somehow the user authenticates or logins in to Shopify, or approves our app temporary access to their data.
Our app performs the calculation for the user, ending data access
Any ideas as to how this authentication or access of data can be facilitated? Shopify doesn't seem to have a 'login with Google' kind of authentication button.
Thanks!
There are two modes for authenticated access, namely Online and Offline. What you need in this scenario is Online Access.
From Shopify Docs
Tokens with online access mode are linked to an individual user on a
store, where the access token's lifespan matches the lifespan of the
user's web session. This type of access mode is meant to be used when
a user is interacting with your app through the web, or when an app
must respect an individual user's permission level.This access mode
must be explicitly requested in the authorization phase.
It should also fulfill your needs related to ending data access.
An access token created with this access mode is temporary, and is guaranteed to expire after some amount of time.
When a user logs out of Shopify admin, all online mode access tokens created during the same web session are revoked.
Once you have the access token, you can use Shopify API to query data so that your users don't have to upload any files manually.
I am implementing a functionality of removing a user account (the user will have the possibility to delete its account).
I am using Auth0 as authentication provider. If I log in the app using a Gmail account, Auth0 will create the account with user ID value of XXXXX. After I delete the user (through API or from users management section), if I try to access the app again with the same Gmail account then the user ID will still be XXXXX.
This is a problem in my case because I need to anonynimize the data and the other details should never be visible.
I can solve the problem by changing the the ID in my database but for the moment I would like to keep it.
Is this the normal behavior of auth0?
Good morning tzortzik! I work with the Auth0 Community team and after confirming with one of our senior engineer, some connections the user ID is built based on details originating from the external IDP (Google in this case). That being said, if you remove a user in Auth0 for this instance, the very next time the user logs in/signs up they will receive the same ID that originated from the external IDP. I hope this helps clear some things up. Thanks!
Account Linking provides several ways of linking users to their own accounts such as their Google account or Twitter account.
I chose OAuth in Actions on Google website to do OAuth 2.0 Authorization Code Grant for obtaining access token in exchange for data resources. When I linked a user to a Google account Google Sign-In enabled, the fetching of user information was easy because the data is stored under payload, but OAuth implementation does not seem like it produces user data under payload inside User object.
So should I make an API call to the third party to fetch the user data and store that personal data to a database in this case? I wondered if there is a way that Google prepares on behalf of developers. If not, then greeting a user who visits my app again by saying 'Hello, {person name}' gets tedious...
You have two options with Account Linking.
In the case you describe, you're providing an OAuth endpoint and getting an auth token from the Assistant, and you are responsible for taking this token and using it to determine who the user is so you can get whatever you know about him. The token is one that you issue and control, so presumably you have that info in your database already. If you are reusing a token from another service, that service should be able to tell you who they are.
It sounds like you're using using a Google Sign In, however, in which case it is easier to use Google Sign In for Assistant. Once the user has signed into your service (either through an app or webapp) and granted permission to your service, then they will also be able to gain access through the Assistant. You will get an id token which can be decoded to get profile information about the user including their Google ID and name.
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.
Does anyone have clues about how to do this? I'm basically trying to replace the strategy for "Connect With Google" from OpenID to OAuth. The challenge is identifying an old user (user on Google open ID) when a user signs in under the new OAuth scheme.
I have a working implementation which relies on email address as the primary key, as the open ID strategy captures that. The problem is, I don't want to ask for email in the OAuth flow. The ideal value is simply Google user ID, but the Open ID strategy doesn't seem to capture that.
So I have open ID tokens like https://www.google.com/accounts/o8/id?id=AfSCwGQ4PUaidXSQddJugXKLqU5V0MrXFhJM6UHybPw and trying to understand if I could get a Google ID from that.
UPDATE: I explained here how I ended up doing this migration - http://softwareas.com/migrating-user-accounts-from-google-openid-to-google-oauth-to-google-plus
We don't have a strategy ready today that avoids the user seeing another approval page.
However, rather than attempt to do an OAuth1 based hybrid flow and have to add all that legacy code to your server, I'd suggest you simply correlate on email address and move to OAuth2 login. I'm assuming you're like the majority of sites that end up asking for email address because they usually want it for account recovery. Just make sure you get the email address from OpenId as one of the signed parameters.
Then use the userinfo.email scope and OAuth2 https://developers.google.com/accounts/docs/OAuth2Login and you should be able to migrate with less developer pain.
In addition, we're in the process of adding support for OpenIDConnect and it supports a parameter of login_hint so you'd add &login_hint=bob#gmail.com to your authorization URL and it will steer the approval to the right account. This is not documented right now but it may be useful for you to try it. The user's browser could be logged into Google with a number of accounts and you want to try to get the right one. Always check the email you get from the OAuth2 flow to make sure it matches since this is just a 'hint'.
Users will still have to re-authorize for OAuth2, but we have plans to skip this reauthorization in the future. The main point is to plan on using OAuth2 and we hope to deliver a seamless migration soon and you'll be on a supported protocol.
Google uses directed identifiers for OpenID that are unique per relying party and are explicitly designed to conceal any correlatable identifier for the user. So the short answer is, no there's no way to get a Google ID that corresponds with a given Google OpenID.
One option, however, might be to use Google's OpenID+OAuth Hybrid flow. This allows you to get an OAuth token as part of a normal OpenID flow, which could then be used to get the user's ID from the OAuth2 Login API, which you can then associate with their existing account. Once you've done that for all of your existing users, then switch to using the OAuth2 Login directly.
The trick, of course, with this approach is getting all of your users to login again so that you can send them through the new flow. That will come down to how long you're willing to wait to migrate accounts, and whether you're willing to prod existing users by emailing them and asking them to login again (similar to a forced password reset).