I would like to know if the following scope URI would be affected by the Google+ shutdown or not.
https://www.googleapis.com/auth/plus.me
This scope is named "openid" in the "OAuth consent screen" tab of Google API Console and has "plus.me" in the URL.
The openid scope is default setting.
But the following URL says "only projects directly requesting the 'plus.me' scope are affected".
https://developers.google.com/+/api-shutdown
It confuses me...
Is the above scope URI affected by the Google+ shutdown?
Also I would like to confirm each of the following scopes and endpoints will whether be affected or not just in case because I'm using them on my project.
scopes
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/userinfo.email
endpoints:
https://accounts.google.com/o/oauth2/auth
https://www.googleapis.com/oauth2/v3/token
Will the above scopes and endpoints be affected?
Thanks
I would like to know if the following scope URI would be affected by the Google+ shutdown or not.
https://www.googleapis.com/auth/plus.me
Note: This is not a uri it is a scope. The scope is being shutdown. You will not be able to use this scope when authenticating users to Google.
What are scopes
Different pieces of user information are often stored across a number of online resources. Users may upload and store photos with a service like Flickr, keep digital files on Dropbox, and store contacts and events in Google Calendar or on Facebook.
Often, new applications will want to make use of the information that has already been created in an online resource. To do so, the application must ask for authorization to access this information on a user's behalf. Scopes define the specific actions applications can be allowed to do on a user's behalf.
Shutdown what?
The documentation for the API-shutdown is not very good and can be a little confusing.
Beginning March 7, all OAuth token requests with scopes starting with "plus." (i.e. "plus.me", "plus.login", "plus.profile.emails.read", etc) will fail upon request, and may start to intermittently fail as early as February 15, 2019.
This being any scope starting with the word plus. If we check Google scopes This gives us the following.
So yes https://www.googleapis.com/auth/plus.me is being shut down the others you have listed are not.
Related
I am trying to publish a Google Sheets Add-on. I am working on the Google Workspace Marketplace SDK configuration. The configuration automatically includes the following 2 scopes as defaults:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
The Add-on has no reason to access the user's email or profile. Why are these added? Can I delete them? The only scopes that the script code should need are:
https://www.googleapis.com/auth/script.container.ui
https://www.googleapis.com/auth/spreadsheets.currentonly
When I go to create the OAuth Consent Screen. I am told that I need to create "A Youtube video showing how you plan to use the Google user data that you get from scopes". Am I being asked to do this because of these default scopes that are included?
EDIT: I deleted these 2 scopes and did a SAVE. It confirmed that the edits were saved. But when I refreshed the page, the scopes were back!
The reason why the Trust and Safety team is asking you for the video is because this:
1-Most of the apps that will be public, require certain steps. So the video is one of those.
2-Now, the main reason for the video, is because the scope https://www.googleapis.com/auth/script.container.ui is part of the restricted scopes. And according to the documentation it needs to go through the verification.
So basically the reason for the video is because you have a restricted scope because this scope allows you to display and run third-party web content in prompts and sidebars inside Google applications. Therefore, it is important for the verification process.
Now in regards to your concern of the default scopes, I was able to remove them and create OAuth consent screen without them.
I have a running website, where users already have accounts. And I am trying to create a Google Assistant agent, accessible on Android, to help users access their information.
My issue is that I can't detect returning users on Android Smartphones, each time they have to sign in.
I tried Anonymous User Identity, but it is soon to be deprecated.
Is there an other way to keep track of users?Using some kind of userId that I can store, so I can make "my own Acount Linking" linking the person/Smartphone with already existing user accounts.
There are a few angles to your question.
Is there any way to keep track of users?
Yes... but...
You can store a userId that you generate in the user storage area. You do need to treat this like you would a cookie, so some jurisdictions might impose restrictions on this, but this is one approach to moving from the anonymous ID that is being turned off soon.
But...
How do I let them log into my service through the Action?
That is the problem. The General Policies states the following limitation for collecting user data:
Authentication Data
(including passwords, PINs, and answers to security questions)
Don't collect authentication data via the conversational interface (text or speech).
After a user's account has been linked, PINs or passwords may be used as part of a second verification process.
So you need to use Account Linking to connect to the existing account on your service.
How can I do Account Linking if I don't require Google Sign-In?
You can still use Google Sign-In for Assistant if it will (or may) provide the information as part of the profile that match what you have. So it doesn't need to use the same account - just have the same email (for example).
But that still may not be enough.
For other cases, you can look into setting things up to work with an OAuth server that you control.
So why use Google Sign-In if I setup an OAuth server that uses Google Sign-In?
Google Sign-In is good for a more streamlined flow, if you can use it. It can be done completely with voice, such as with a smart speaker, instead of requiring the user to go to a phone to complete the login. So if you have the user's email address in your account system, and you also get this from Google Sign In, then you can connect the two accounts.
In some cases, such as if the user is expected to have logged into the account on your website first, they won't even need to do that. If both the voice client and web client use the same Google project, then authentication will take place automatically.
I've read about security best practices saying that inactive user accounts should be disabled and even deleted to avoid security issues like unauthorized use. I can see that being true for regular username and password authentication sites, however my application was built to work only with Facebook groups and as such the only way to login or create a new account is to use the Facebook login.
The argument can be said that someone malicious could take control of one of my users' Facebook accounts and then use it access my application. Although that is true if they have control of a Facebook account my application would never know it's a malicious person so I don't see that as a valid criteria to use in determining if the account should be disabled.
Furthermore if a user is inactive and wants to become active again since it's Facebook login there really is no reason for them to go through some kind of reactivation process like confirming their email or changing their password.
I must be missing something here because it's certainly mentioned as a best practice to disable accounts but since my only login method is Facebook (OAuth) I can't come up with a valid reason to disable/delete inactive accounts.
Regarding other methods of unauthorized access I have security measures in place so I'd like to keep the answers relevant to the login method.
Please enlighten me if I've missed something.
If you have decided that your application needs to use Facebook authentication, then your system's identities will only be as traceable as Facebook's identity management permits. (And don't expect Facebook to help you by disabling / blocking users at their end ...)
You need to design it accordingly:
Don't make any assumptions that users will behave properly.
Don't rely on login controls to keep out malicious users.
Put in your own (sufficient) defenses against malicious behavior into your own system.
You are correct that disabling an account in your system won't achieve much if you also allow the user to (easily) reenable it. Given that it is easy to create (effectively) untraceable Facebook accounts, the chances are that a typical malicious actor will not just rely on old accounts. They may use a brand new account and connect from an IP address that you have never seen.
There are some things that you could do though. For example, implement mechanisms to do the following:
Make sure that users simply cannot upload dangerous content (e.g. files with trojans, web content with dangerous links or scripts.
Allow administrative locking an existing account or OAuth identity,
Allow blocking of creation of accounts or access in from specified IP addresses or ranges,
Keep an audit trail so that you can watch the history of user behavior.
This was working fine for many months and now it's just a blank space. I get the following error: Error from Instagram: The access_token provided does not match an approved application. How can I get a new access_token for an existing client??
You need to check you application hasn't been put into sandbox by Instagram. They made big changes to their API on the 1st of June and if you had it submitted your app for review it will be put in sandbox mode and only sandbox users will be able to use it.
Even if you are not in sandbox mode you may need to get your users to reaurhorize your app due to new scopes being used to control access to everything other than basic user information.
Check Instagram Developer Docs for more information on the changes
You need to check your Access token's Scope and asking for login permission
where some new Scope had been added ex:public_content Added. Also don't forget to check for requirements Scope for API you are using and if it's need and Authentications "Valid access Token". where also had some changes.
basic - to read a user’s profile info and media
public_content to read any public profile info and media on a user’s behalf
follower_list to read the list of followers and followed-by users
comments - to post and delete comments on a user’s behalf
relationships - to follow and unfollow accounts on a user’s behalf
likes - to like and unlike media on a user’s behalf
And take look about **Sandbox API behavior of your application not life yet :**
API Behavior
The behavior of the API when you are in sandbox mode is the same as when your app is live, but comes with the following restrictions:
Data is restricted to sandbox users and the 20 most recent media from each sandbox user
Reduced API rate limits
The first point is important and it means that the API behaves as if the only users on Instagram were your sandbox users, and the only media ever posted were the last 20 for each of these users.
For example, if you query the /users/{user-id}/ endpoint and the {user-id} is a sandbox user, then you will get the normal API response; but if the {user-id} is not a sandbox user, you will get a APINotFound error.
As another example, let's consider an endpoint that returns a list of media: /tags/{tag-name}/media/recent. The response returned by this endpoint will contain only media with the given tag, as expected. But instead of returning media from any public Instagram user, it will return only media that belongs to your sandbox users, restricted to the last 20 for each user.
Good luck
The following video clearly explains what steps to follow to get this working with the new auth
https://www.youtube.com/watch?v=0k4RhTS94Hw
Kind Regards
Sandeep Sahoo
We have a client who has a simple Instagram feature on the site to pull photos by a certain tag. They just noticed it isn't working. Getting an error - invalid access token. I guess since the 1st because of the updates. We didn't used to need an access token since we're not doing anything with users - just tags.
Now it looks like we need one and the documentation makes zero sense on how to obtain one. And it seems like they're not accepting most apps. The app is in sandbox mode too. So I'm assuming it's because it got switched to that? Got no notification of this happening.
The first step in documentation to get an access token is "Direct the user to our authorization url." What does that even mean? There's not a link provided or anything. It also says "Company Name, Contact Email and Privacy Policy URL are required to start a submission." Our app doesn't have a privacy policy... it's just a simple tag feed. I don't understand why everything is so complex to have a simple tag feed.
Is there a wait time to get the app approved..if it gets approved... Do I have to have it approved before getting an access token? This isn't outlined anywhere.
You got it right. As of June 2016 any Instagram API calls require an access token.
Getting an access token is described in the documentation. App approval is not required.
There are two ways to get one: server-side or client-side. The second option (called implicit authentication) can only be used when implicit OAuth is enabled in the client settings (Manage Clients > Edit Client > Security > Disable implicit OAuth). It is disabled by default.
In either case you need to redirect the user to the authorization URL to obtain an access token.
The URL for explicit mode (server side) is:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
The URL for implicit mode (client side) is:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token
After this you will be redirected to the REDIRECT-URI, which will be passed an argument. For explicit mode this will be a query string with a code, while for implicit mode you will get the access token directly as a hash:
http://your-redirect-uri?code=CODE
http://your-redirect-uri#access_token=ACCESS-TOKEN
For implicit mode you can then get the access token from the window.location.hash in Javascript.
For explicit mode, however, you need to further process the code to obtain the access token. You can read how this can be done in the API Documentation. I'm not going to take this any further here.
The problem is that every user who wants to see your feed needs to login to Instagram (and have an account) in order to view it. In your case this might not be desired. However, there are a few options to get around this (rather annoying) problem:
You can reuse your own (already obtained) access token(s) to display the Instagram feed for every user. You will need to be aware of rate limits for each token. For sandboxed apps this is 500 API calls / hour, while live mode allows 5000 API calls / hour. [source] You could store tokens in a table and use them in a round-robin manner, to allow more API calls. This involves manually obtaining a bunch of tokens which your application can use (the more the better). This might not be the ideal solution considering Instagram doesn't warrant access tokens to have an unlimited lifetime.
You can retreive JSON data without authentication by appending /media/ to a user page URL, as described in this post. No tokens or client IDs are required for this to work. However, this only works for users, not for tags. Besides, Instagram doesn't document this feature so it is not garanteed to work in the future.
You can use an aggregator like Juicer or Dialogfeed instead which will handle access tokens for you. This is usually not free of charge.
I'm also in the process of making an Instagram feed for my website, and this is what I concluded from my research. Please bare with any errors I made.
Edit: Here are some more limitations for sandbox apps.
In sandbox mode you can only access data from sandbox users (thus users who received a sandbox invite). This means that:
Media retreived by user, e.g. /users/{user-id}/media/recent, will return an empty response if the user is not any of the sandbox users.
Media retreived by tag, e.g. /tags/{tag-name}/media/recent, will only contain tagged media belonging to sandbox users.
Thus, for a tag feed to work, it needs to be live (reviewed and approved). If you don't want to do this, the only alternative is to use an aggregator as I mentioned above.