I want to develop and publish a bot for Teams, to interface with my SaaS (I already have a Slackbot that I'm porting). I'm creating a Bot Channel Registration as per this guide and came across the choice of whether to auto-generate a new App Id and password, or manually registering one (described here). I already have an Azure AD app for my SaaS that is published to the AppSource marketplace (the integration currently mainly allows logging in with your M365 account and syncing users from AD). Is it possible, and would it make sense to use the same App ID for the bot I'm developing for the same SaaS? Or is it somehow not advisable? And relatedly, can I expand my existing listing on AppSource to also contain the new bot, or should this be a separate listing?
I noticed in the documentation for manual registration of a bot, that it says that bots only work with "Accounts in any organizational directory and personal Microsoft accounts (e.g. Xbox, Outlook.com)" - my existing app only works with organization accounts, not personal accounts (since it's a B2B app) - does that change things?
Perhaps consider the question the other way - is there any good reason TO re-use the app ? It's very easy and basically free to create an additional app, and that way you don't run the risk of possibly ending up with settings needed for one scenario that conflict with another scenario's requirements, now or in the future. Here are some other possible considerations though:
new apps require Publisher verification, since 9 Nov 2020. This won't affect you for an internal app, which can be consented to by a global admin.
If you need the user (or admin) consent for some set of privileges (e.g. delegated Graph access), then using the same app might make sense. An example, in a Teams context, might be a bot and a tab that both need to access something from the Graph on the user's behalf. You could get consent in one context, and use it to access the resources from both contexts.
In a nutshell, and especially without a really really good idea of both of your current and planned use cases, it's hard to give a really solid 'yes' or 'no'. My gut says go with a separate app for a separate, unrelated scenario though.
Reusing the same appid against any other B2B won't create any problem. Being said that you can't use the above app if you're planning to implement/use BOT framework with it, as it's registered for organization only.
If you plan to create BOT related app registration then i would
suggest you to create new app registration with Organization +
personal for you scenario.
Please see the documentation and it's disclaimer:
In the above document it's pretty clear if you create any other app registration (other than Organization + personal), then the BOT will be unusable.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
I'm exploring accessing mail (and sending mail) on behalf of other users. I have read about the graph api which would allow me also to handle chat messages later on.
I wanted to start implementing this with my personal account (#outlook.com) and followed basically this tutorial: https://cmatskas.com/create-a-net-core-deamon-app-that-calls-msgraph-with-a-certificate/ (this seems to be the same as the walkthrough in the portal)
I found questions and answers (like Microsoft Graph to send mail with Client Credential Flow (application permission) and personal account) but I do want to create a daemon app which seems not to work with a personal account (which makes sense because I could read Microsoft's end user customers data).
Furthermore, when trying to create such an app there is the following warning:
If I would create a development env for this I am still now working at a verified publisher, so I cannot develop an application to see if it fits our needs?
It is possible to have a developer sandbox from Microsoft for that purpose.
See https://learn.microsoft.com/en-us/office/developer-program/microsoft-365-developer-program-get-started for information on this
In my application I want to be able to programmatically create and delete user accounts in Azure Active Directory. This program needs to run unattended.
I am able to create Azure AD users but keep getting failures when deleting a user account. Specifically, I am getting the following error message:
Microsoft.Graph.ServiceException:
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
I think this is by design because the documentation states that only delegated permissions are supported. Can someone from MS Graph team confirm that it is not possible to delete AD users in unattended fashion (e.g. without prompting for admin user account and password)? Is this functionality going to be supported in the future?
Are there different ways to solve this problem? Would the Azure AD Graph API work for this (even though it is not recommended to use now)?
That is correct, DELETE /users/{id} requires Directory.AccessAsUser.All which is only available for delegated scenarios.
This is unlikely to change given the security exposure this would introduce. A rogue application creating users would certainly be extremely annoying, but a rogue application deleting users would be outright catastrophic.
My suggestion would be to have your application maintain a "deletion queue". Whenever you need to delete a user, simply add that id to the queue. Then provide an interactive experience for Admins that allows them to login and delete the queued users after reviewing the list.
I have an app on store and all client are used it. Sometimes some client needs additional feature that isn't wanted by others so in that case I make AdHoc build for that particular client, but it is not proper solution.
I think on Enterprise solution but apple not allowed to distribute outside the organization in it and I have all users are clients.
If your app has a user login, download a user specific configfile directly after login and check in code for feature availability by looking into it. Large companies like Spotify and also startups do it this way to test new features without releasing them to all.
I'm working on a Slack app that also links with a web app, which users can log into using Slack. It's very common for a new user to need to both log into the web app and add the app to Slack.
I'd like to let them do this with a single trip through OAuth. Since the web app needs a name, email address, and profile picture for each user, I added the "identity.basic", "identity.email", etc. scopes to the ones requested by the "Add to Slack" button. But it turns out that Slack doesn't allow this. The Slack OAuth page says "Invalid permissions requested: Cannot request both identity scopes and other scopes at the same time".
One alternative might be to request the users:read and users:read.email scopes instead of the identity scopes. But this gives our app more access than it needs; it just needs the info for the current user, not for all users on the team. (It might later need that info for all users, so I'm considering doing this anyway, but I'm not sure if users would like it.)
The other alternative seems to be to make the user go through two different OAuth permissions screens. But this seems cumbersome and not a good user experience.
So the questions are (1) is there a better way, and (2) why doesn't Slack allow combining the identity scopes with others?
UPDATE to clarify, in response to the answer from #erik-kalkoken:
I'm aware of the differences between "Add to Slack" and "Sign In with Slack". I certainly don't intend to take away the option for most users to do a simple "Sign In with Slack". However, with this particular app, it makes no sense to do "Add to Slack" without also being signed in to the web app. This needs to be done by one person per Slack team before other users on that team can use it. Our onboarding process for new teams is a bit cumbersome, and I'm looking for ways to make it simpler and smoother. Since the sign-in and add steps could theoretically be combined into one step, I would prefer to do that.
Part of this may be because we aren't developing a "Slack app"; we're developing a Slack integration for a web app. The web app can be used without using Slack, and has its own concepts of users and communities.
The "better way" in my opinion would be to not combine these two functions on your website, because their effect is very different. I would argue that it would be confusing to users if they are combined and would not make a good user experience.
"Add to Slack" is installing a Slack app for the whole Slack team. You only do this once and its usually done by the admin of a Slack team.
"Sign in with Slack" is used to authenticate any user of a Slack team. You would use this function every time you log into your app and its used by many users of a Slack team.