We have an existing app that's registered in the Google Apps Marketplace. We now need to retire one scope that it uses and add another.
We are trying to decide whether we:
delete and add in one go; or
add the new one and then retire the other one at a later date.
I appreciate that adding a scope will require an admin to grant access to the App again, but can anybody confirm the impact of removing a scope? Does that also cause the admin to grant access again?
In short: does any change require admin intervention, or just scope additions?
Old scopes (that were requested and approved by user and you delete them from your marketplace SDK configuration page) that were approved by user at certain time will still remain approved for the user until he revokes the data access and re-grant it again.
New scopes as said by KENdi will not be approved until user approves (re-grant) access again, though all old scopes still will be available for you.
AFAIK you can add a new scope with the Google Apps Marketplace without deleting the old or unused scope. But take note note that your customer will still need to grant the access for the new scope/s in the ADMIN console.
Based on this FAQ, to update OAuth scopes, enable new extensions, and other application settings, go to Google API Console. Click APIs, then go to the Configuration tab under Google Apps Marketplace SDK.
For more information, check this documentation.
Related
I generate a auth link like:
https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?access_type=offline&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar.events&prompt=consent&response_type=code&client_id=xxx&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Fapplication%2Fsettings%2Fgcal&flowName=GeneralOAuthFlow
As you can see I call for the authorization as defined in the documentation here https://developers.google.com/calendar/api/guides/auth however, when I go to auth this is what I am presented with: and I thought this might be some new security thing from google but then I look at connecting to other sites and the account works just fine there.
This application is also fully verified for the consent screen.
While doing some comparison between my calls and other site's I notice that mine have /v2/ in the path while others do not. I have tried multiple individual google accounts with same result, but I always get a v2 redirect.
Anyone here know why this happens with v3 accounts and how I can solve it?
Unfortunately, this is the new default behaviour
It is realted to the new policy of More granular Google Account permissions with Google OAuth and APIs
It is being gradually introduced and is not related to either v2 or v3 accounts are being used but rather will eventually implemented for all accounts
Should the user not grant you all the scopes necessary for your Addon to run - you will need to handle it programmatically checking which scopes have been granted and requesting additional scopes if required
Best practive would be to make it very clear to your users PRIOR to the app installation that checking all checkboxes is crucial for the correct functionality of the app.
There is a very good stackoverflow post that explains the new change more in detail and includes many useful references.
I have a custom application for internal use only where currently users are created by a super admin. Some of the users are from within the business and some external e.g. suppliers/customers.
I'm looking for a way to integrate MS Active Directory as a login option but want to be able to restrict which users from the business can actually use this method.
I have search through all the MS docs and have all the documentation on the different oauth approaches but not sure which one would be suitable for my needs.
I am thinking that perhaps i need to give the admin a way to browse the AD and select the users that can login which then creates inactive user accounts in the mysql database with some sort of MS user ID. Then provide a 'Sign in with MS' button that does the usual auth redirection process to MS and back to the site. At that point I can check an ID and if that matches an allowed user account and if so, sync the rest of the data e.g. name, email, phone etc..
Links I've already found:
https://learn.microsoft.com/en-gb/azure/active-directory/develop/authentication-scenarios
https://learn.microsoft.com/en-gb/graph/tutorials/php
https://github.com/microsoftgraph/msgraph-training-phpapp/tree/master/Demos/03-add-msgraph
Your first order of business is enabling a user to sign in to the Laravel-based app. For this, I strongly recommend not trying to re-invent the wheel (at least not completely), and make use of an existing Laravel package. Laravel Socialite is probably the best place to start, since it has a long list of existing community-provided Socialite providers, including three which work with Azure AD already: Microsoft, Microsoft-Graph and Microsoft-Azure. (Note: Though I haven't tested any of these myself, the first two seem to be the most promising, as they use the newer v2 endpoint.)
When it comes to authorization (controlling access), you have two options:
Control at Azure AD
Once you've got the app integrated with Azure AD, you can configure the app in Azure AD to require user assignment, and then control access to the app by assigning (or not) users to the app. Users who are not assigned won't even make it past the sign-in page.
You can use Azure AD's existing experiences for managing user and role assignment for the app, or you could go all-out and build this experience directly into the Laravel-based app itself, making use of the Azure AD Graph API to create the [app role assignments](https://learn.microsoft.com/en-us/previous-versions/azure/ad/graph/api/entity-and-complex-type-reference#approleassignment-entity and user picker experience.
Hint: In either case, remember that you can make the app "superuser" an "owner" of the app in Azure AD (Azure AD > Enterprise apps > (app) > Owners), which will allow them to assign users without needing to give them any additional privileges in Azure AD.
Control at the app
In this approach, you allow all users to sign in to the app with Azure AD, but then you use your app's own authorization logic to decide who makes it any further, and what roles they get in the app.
In reality, you will most likely find the best approach is to use a combination of the two, with some of the authorization enforced by Azure AD and the next level enforced by the app itself.
If you would do it in this way, it will be necessary that the super-admin has always this permissions in the AAD. From my point of view it is less practical.
I would perfer such app-assigments with help of Service Principal. You assign a role (look for app roles) to the user and then your business logic must decide which permissions the user has. If you would use the app roles feature, then you can restrict access to the role with it's help. All the user can login, but only users with a specific role would be able to see a content of the app.
I hope this hints can help to find a right direction, but there is no silver bullet solution... :/
We have changed the required scopes of our application in the marketplace SDK but on install the app is still requesting the old scopes.
What are we missing?
See also:
https://issuetracker.google.com/issues/72450194
Based from this link, old scopes (that were requested and approved by user and you delete them from your marketplace SDK configuration page) that were approved by user at certain time will still remain approved for the user until he revokes the data access and re-grant it again. This may be the reason why the old scopes are available. Also from this documentation:
To update OAuth scopes, enable new extensions, and other application settings, go to Google API Console. Click APIs, then go to the Configuration tab under G Suite Marketplace SDK.
We have an existing web app which uses Google's OAuth 2.0 APIs for Admin Directory, Drive, etc for administrative tasks like backup and audit.
Currently we let our customers install backup and audit independently as 'modules' and each have separate client_ids and separate OAuth scopes (i.e. Admin directory for one, Drive for another).
We want to bring our app to the Google Apps Marketplace, and take advantage of Google Sign In (OpenID Connect), use service accounts with domain-wide delegation of authority, but still let our customers only authorize scopes they want to use.
Can we add new scopes to Google Apps Marketplace apps when a user wants to enable a certain feature?
The best practise guidelines (1) indicate that we should request all scopes we might want up front via the Marketplace SDK scopes section but we want to only request the scopes our customers are going to actually use.
(1) https://developers.google.com/apps-marketplace/practices#1_complete_the_listing_review_request_form
You can add new scopes. Your customer will still have to grant access though for the new scope/s from the ADMIN console.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.