I have an extension that is working perfectly correctly using chrome.identity.getAuthToken (https://developer.chrome.com/apps/identity#method-getAuthToken). I need to submit the oAuth consent screen for verification as it uses a restricted scope.
I received an email from the Google OAuth certification team about the creating a video showing the step by step of the auth procedure, all fine except for one step that states I need to show the:
URL bar of the OAuth Consent Screen shows the Client ID containing the
project_number fully displayed (Note: this is not required for native
Android and iOS apps)
I am stuck here as the oAuth Indentiy API providor used by chrome.identity.getAuthToken shows the consent screen in a window without any URL bar! I can't see any options to change this or show it....
What should I do?
Refactor the auth to a popup rather than using the
chrome.identity.getAuthToken
Try submitting without and see if it goes through?
Thanks for your advice.
So, I replied to the OAuth verification team an explain that chrome.identity verification screen does not show the URL bar and received an acceptance less than 24 hours later.
My recommendation to anybody requesting verification and worried, is just go for it and explain where you cannot meet what they have asked.
Thanks
Related
I am testing the POST method to send our users Alerts via the Admin API page linked below and I have two questions.
First, what is the SkipInbox setting supposed to do? From my testing, it makes no impact within Banno or to push notifications. Is the setting meant to skip sending an email notification of the alert?
Second, how is the DeepLink supposed to work? In testing, I do not see a link within the alert or the push notification. Is this also specific to an email notification of the alert?
https://jackhenry.dev/open-api-docs/admin-api/api-reference/v0/alerts/details/#/Send%20Alerts/post_a_mobile_api_v0_institutions__institutionId__users__userId__alert_send_generic
First: [Edited] The skipInbox request parameter is deprecated and should not be used. The functionality for that parameter is not implemented.
Second: The deepLink parameter isn't supported yet in the Banno Online + Banno Mobile (Android / iOS) client apps.
So, I am trying to get my Gmail add-on approved by Google and I am struggling with one last thing.
My app use "sensitive" scopes (such as gmail.addons.current.message.readonly) and therefore the user needs to authorize that my app is allowed to do that. For apps that haven't yet been approved by Google, the user is prompted with an "Authorize access" button (see image and this link https://developers.google.com/gsuite/add-ons/how-tos/authorizing-addons#authorizing_unpublished_g_suite_add-ons).
Now, I have received feedback from the OAuth Verification Dev Team at Google that I have to change this button to the Google brand guidelines. My problem with this is that the screen that needs to be changed is a default Gmail Authorization screen (for unverified apps only) and I dont know how to change that...
Does anyone have any idea how to proceed? I have emailed the OAuth devs mutiple times, but they dont provide me with any pointers, only threats that my app will be rejected if I don't comply.
UPDATE: The full response from the Google team below:
Thank you for your response.
Please note, that since the 'Authorize Access' button initiates the OAuth Sign-in process it is subject to comply with the Google sign-in branding guidelines.
You may refer to Figure 2: Unverified app authorization flow on our
OAuth Client Verification page, which showcases the full OAuth
Sign-in process.
Google Sign-in Branding
In order to proceed with the sensitive scope verification for the project: xxx-xxx, please update the previously flagged Google sign-in button so that it complies with the Google sign-in branding guidelines.
Please reply to this email once you have made the appropriate updates to your site and/or your OAuth Consent Screen so that we may continue with the verification process.
Note: Failure to satisfy/provide the preceding information might
result in a rejection of your request. To avoid this outcome, update
the applicable information in your request to meet our requirements.
Update: I can confirm that simply requesting verification, as long as the scope isn't used in the app, does not trigger the unverified app screen.
The current documentation for when the "unverified app" screen is displayed is slightly confusing.
In particular, what happens when I add a sensitive scope via the Oauth Consent Screen, request verification, but do not use it in the app yet?
The unclear part of the support page is below, in particular point #2:
The app or script might display an "unverified app" screen before it
displays the consent screen. This is based on the specific scopes that
your app includes in the request. This warning will display when:
Your app uses sensitive scopes and you haven't configured your OAuth
Consent Screen and requested verification.
You selected sensitive scopes on the OAuth Consent Screen and requested verification, but the verification is in not yet complete.
Your app uses sensitive scopes that you haven't selected on the OAuth Consent Screen configuration page.
The way bullet #2 is worded reads like this may trigger the unverified app screen for users, even though the scope isn't in use.
I may be missing something, but it feels like the intended behavior is to allow users to request verification and only show the "unverified app" screen if the scope is also in use in the app, so as to allow developers to get a scope verified before using it in the app.
After we went ahead and requested verification I can confirm that simply requesting verification does not trigger the unverified app screen, as long as the scope isn't used in the app until it's verified.
I am trying to authenticate using OAuth2 with Google Maps Coordinate but I am having an issue when specifying the scope that I want the Auth tokens to be valid for. The URL I am using to request an access code is in this format:
https://accounts.google.com/o/oauth2/auth?response_type=code&client_id={client id}&redirect_uri={App URL}&approval_prompt=force&scope=https://www.googleapis.com/auth/coordinate
The issue I am having is that the consent screen just says "This app would like to: Have offline access". It does not mention granting permissions for interacting with Google Maps Coordinate. I am starting to think this a bug on Google's side, because if i try to get a read only token by adding .readonly to the end of the url, the consent screen shows "This app would like to: View your Google Coordinate Jobs". Similarly, if I replace coordinate with docs or drive, I get the correct consent screen where the app requests permissions to access and modify Google Drive content.
If I get a token using the coordinate scope with the "Have offline access" permissions and then use that token to try and make requests to coordinate, I just get "Insufficient Permissions" errors.
The issue only seems to be happening when trying to get an access code for Maps Coordinate. Has anyone else experienced this issue?
Thanks
This is not a bug, this is just a strange behaviour (and maybe a bug). (so it may be not 100% correct, what I'm telling)
You use in your request url approval_prompt=force, that means, that the user will always be asked to give permission. What follows is, that you get a refresh token (that doesn't expires, unless the user removes explicitly the permission for your app from his account), which you have to exchange for an access token.
That is also the reason, that you always get only "This app would like to: Have offline access". Once you permitted a specific scope, it won't show up anymore in the consent screen.
The docs and drive consent screens are showing the right, because you didn't give the permsission for them.
I see basically two possibilities for you: don't use approval prompt (and thus skip the consent screen after the first authorization, you will be simply redirected as the user clicked allow, but without clicking allow) or exchange the token to a refresh token.
Or try revoking your permission for your account.
I think when it shows Offline Access it means you've already accept these permissions before. This has sometimes happened to me, try revoking the old access and try again to obtain fresh tokens. Go to you Google account page (https://www.google.com/settings/personalinfo) --> Security --> Account Permissions --> View All, then search the Maps access and revoke it, then try again
I was following the steps from box.net document
http://developers.box.com/get-started/#authenticating
I can get a ticket as it said first.
Then I use that ticket at following url https://www.box.com/api/1.0/auth/{your ticket}
in a browser, it works as it says. the browser will direct the user to box login page.
In that login page if I input username/password for login.
I can get the auth_token as the document says.
The problem is while I didn't choose username/password for login but use google openid to login an box account.
I will not able to get that auth_token as the document says. the returning response with following status:
not_logged_in
I want to know if this is a bug or I not correctly using the API to get that auth_token.
As many of box user now are using google openid as primely login choice this seems an common use case need be supported.
If anyone know the answer would be very appreciated.
Thanks
If a non-OpenID user is able to authenticate through the Box API's standard authentication process, then your code is fine. We have had reports of issues for our Single Signon issues, so this is likely a bug on our end.
Just make sure your app can authenticate users who have Box passwords. When we resolve these SSO issues, OpenID users will be able to connect your app without any changes on your end.