I am working on a slack bot project. I have some questions about slack App Credentials, bot tokens, and app-level tokens.
Are the slack app credentials like App id, Client id, Client Secret, and Signing Secret varies when I try to install my slack app on different workspaces or keep the same?
Is the slack bot access token will be the same for all distributed workspaces when the app will be published in the app directory?
Is the app-level token is same for all workspaces or only belong to the app?
Hello there and welcome to Slack app development!
Your Slack app's credentials like app ID, client ID, and client secret are specific to your app and remain constant unless you regenerate any of them or create a new app container. If you're building for the public Slack app directory, your app will also have a development edition with a different set of IDs and secrets. These secrets and identifiers are how you identify to Slack that your app is your app and is entitled to work with Slack.
A bot access token is specific to an installation, each workspace you install a bot user into will have a different bot access token. It's up to your app to switch contexts and use the right token based on the workspace involved in a specific interaction or invocation.
The app-level token represents agency between your app and Slack and does not explicitly relate to any workspace it is installed on. It has a very limited set of use cases, but one of them allows you to connect to the Socket Mode interface for the Events API, from a perspective that includes all workspaces your app is installed on simultaneously.
To receive a bot user token upon each workspace installation, you will need to support the OAuth token negotiation sequence. The Bolt SDKs Slack provides support OAuth.
Related
I'm working on a Slack integration for our workspace that is within an Enterprise Grid. I have a workspace and I've created a Slack App with all possible OAuth scopes and have installed it in the workspace.
I'd like to automatically invite and remove users to our workspace using the app/bot. I should be able to do this with the Slack app/bot using the admin.users.invite and admin.users.remove API actions.
However, these two actions require the admin.users:write OAuth scope, which can only be used on an App that is installed organization-wide, so I can't use this scope on my workspace app:
The app requesting this scope must be installed by an admin or Owner of an Enterprise Grid organization. Also, the app must be installed on the entire org, not on an individual workspace.
Is there any other way I can have an automated system that invites/removes users to/from our workspace, without it being an organization-wide app? This is something I can do as a user through the Slack UI (and I'm not an organization admin, just a workspace admin), so one would think I should be able to do the same things via an app/bot that is installed and authorized to act on my behalf.
Unfortunately, the APIs currently provided by Slack are available for Org Owner & Org Admin roles.
The best course of action for you will be to collaborate with your org admins. Let them manage the app. It means you will not have access to token, but you can use the app as a user.
Create the app that will operate only on your workspace by using fixed teamId.
Ask the org admin to generate the admin token and update that in your app.
May be, if they find your app useful, it can be used across organization eventually.
am not able to retrieve the App basic information for slack-app developed by another member in my workspace
after accessing api.slack.com/apps only my own apps are displayed, how I can retrieve other apps developed by another member in my workspace.
I was expecting to display all apps owned by my workspace
only my own apps are shown
Due to the security architecture of Slack you can not see the app details like its client ID unless you are the owner of the app or the app owner has granted you permission. Your role on the workspace (e.g. admin) does not matter in that regard.
App owner can add additional collaborators for their app. Those collaborators will have the ability to see all details of an app incl. the client ID.
See also this topic:
Best practice to manage app ownership in Slack
I'm facing an issue with new user authentication.
“Application not yet validated by Google.”
I received few weeks ago an email about new policy.
According to email, we are in internal case so no more action is required.
Did I miss something?
An unverified app is a web application or Apps Script that requests a sensitive OAuth scope, but hasn't gone through the Google verification process. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive applications.
You need to go through verification before you launch a user-facing app. You can continue to build and test your application while waiting to complete verification. When your app is successfully verified, the unverified app screen will be removed from your client.
Unverified apps
OAuth Client Verification
internal
Internal apps: if your app is an internal web app for users in the same G Suite domain and the app is associated with a Cloud Organization that all of your users belong to, you don't need to go through verification. Learn more about public and internal applications.
If your new user is seeing this i would suggest you check that they are logging in with their g suite account only those accounts are going to be able to get though the verification requirement.
Just looking for some general advice here.
I want to build a Slack app and publish it publicly to the Slack App Directory, for anyone to use. The basics of the app are:
When you paste a link to a specific domain in a Slack message, a bot will fetch additional information about that link from a Rest API my company built.
The roadblock I'm running into is that our Rest API uses Basic Auth for authentication, and I can't figure how or where in the Slack App setup flow to ask the user to enter their API key.
Does anyone have any advice on how to ask for user input when setting up a Slack app, so that the user can enter their API Key for our REST API?
Thanks!
OK, I will assume that the API key is individual to each user.
I would suggest to ask the API key as part of the installation process for your Slack app on your website and then store the connection between Slack user ID and API key as part of the installation process. It is in fact possible to have individual installations of the same Slack app to a workspace for each user. This is called "configurations" (e.g. the Twitter app for Slack is using this feature).
This requires each user who want to use the app to go through the installation process and also all users need to have permissions to install this particular Slack app (which can be configured by admin).
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.