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.
Related
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.
I have added the 'Add to Slack' button to my web project and it works fine like exchanging the code for an access token and redirecting to a URL of my choice. Now, I am a little bit confused between the 'Sign in with Slack' button. I know that it is used to log individual members in. So does it ask for their organization email and password and log them in or is it for logging in existing slack users? Also, as soon as I click on the sign in with slack button it takes me to a page where it asks me to authorise and leads me to the redirect uri I set for the Add to Slack button.
I see that they both have the same auth flow as mentioned on the slack API documentation except the scope for 'Sign in with Slack' is users.identity.
I am sorry if my question doesn't make much sense as I am pretty new to Slack. Would really appreciate if someone could help me clear some of these doubts about the two buttons
The gist of it is as follows:
Add to Slack
This button is for adding a new Slack app to a Slack team / workspace. You would only run this once for your app and team.
Sign-in with Slack
Is for authenticating existing Slack users to your non-Slack application, e.g. a website. A user will use it every time to sign-in to your website and your website can use it to verify that the user is who he says he is. It works similar to other SSO services, like Google or Facebook sign on, where e.g. .you can use your existing Google account to sign in to a new website.
According to this question: Architecture for merging multiple accounts and registering a user account
Various answers have said that using email is a good way of establishing correspondence between different accounts and then doing automatic merging for multiple account sign in.
However, twitter is a major provider that does not provide email through their oauth API.
How can we reliably and automatically establish a correspondence between a twitter account and for example Google, Facebook, Github... etc accounts? So that we can auto-merge those accounts.
I'm writing a library to help in this, so it's not really useful to say do it manually, since I would like to provide options.
There is no secure-way to automatically do it, I implemented an application with local account/Twitter.Facebook/Google and I didn't have other choice.
I suggest you to allow your users to register with one method (local account, Twitter, Facebook, Google...) and create a page in "My account" that allow them to associate other accounts.
In Twitter a user can be identified by either a name or a key, you have no way to know them unless you explicitly ask them to the user.
Moreover now in Twitter 1.1 you have to redirect your user to Twitter to approve your application and then you get the OAuth token and security key. As you can see there must be an interaction with Twitter, at least if you need to perform some restricted queries on his behalf (e.g. create a Tweet).
I am working with the Firefeed app (based on Firebase) and I am wondering how I can give users the option to both login with Facebook and Twitter.
I correctly set-up my firebase but I guess the issue is that I either use
authClient.login("facebook");
or
authClient.login("twitter");
How can use both to give them the choice? I know, its probably a beginner questions. :)
Many thanks!
I'm not quite sure what you're looking for here. If you want to allow people to log in with either option, then you can simply have 2 buttons, one that says "Log in with Twitter" and one that says "Log in with Facebook".
If you want to have an account system that merges multiple social accounts into a single account on your system, so that users could log in with either system and access the same data, this is a little more complex. There's a thorough answer here:
How can I login with multiple social services with Firebase?
I've got a company web app. I have integrated it without much problems with Twitter.
This means, when a staff of our company creates a new product, it posts onto the company's profile on the Twitter web site as well.
However, Facebook is another story. Facebook encourages registrants to sign up as "individuals".
For example, on the registration page:
You are not allowed to put generic emails such as (support#company_email.com, sales#company_email.com)
You may not have the first and last name as a company entity. For example Foo Distribution or Foo Inc
Their automated system simply rejects any clever attempts to register as a "non-individual". With Twitter, it was a breeze. Since Twitter allows / encourages companies to register an account with them directly, and not as individuals.
Moving along on Facebook, I found out that I can create a 'page'. Which I can use for the company. It has the option of allowing other "individuals" to be admin of the page. However, this would mean that each staff would need a Facebook account.
I don't really like this approach, since some of our staff may be negligent with their Facebook passwords. I rather have our web app have one 'method' of accessing Facebook's API isntead, the way it is done with Twitter.
How else would you go about this?
I'd make yourself the admin of the page, install an app that you develop, and then let your users make posts to the page through that app. This way, you're controlling access to the page while letting your users still have access to it.
You'll need to use an offline_access-enabled access token for this to work continuously (permissions documentation), and if that token changes, you'll have to log in yourself and refresh that token (it can change when you change your password or uninstall/reinstall the app). Additionally you'll need a manage_pages permission, and you'll need to use the access_token for your page that you can find in /me/accounts to make posts to the page.