I am creating a training environment for a 3rd party app linked to slack. In the training, I want users to link a 3rd party app (not my app) to a slack account. I do control the user accounts in slack, and I am the workspace owner in slack.
When the training is done, I want to clean up the accounts by revoking the 3rd party authorization for all accounts in slack. I'd like to script this, and use the API to revoke the authorization. However, all of the endpoints that I look at seem to require that it be done by the 3rd party app itself (or at least to have secrets that I don't have).
Is there a way for me to do this through the Slack API?
Related
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.
Does google API allow us to get 'List of user 3rd party apps authenticated through Google' ?
I can't find any references in documentation. But, it seems like it should be in API
https://support.google.com/a/answer/6294828?hl=en#zippy=%2Cautoprovisioning-status
If I understand correctly what you need is to get the list of all the third party apps that your users have logged into using their Google accounts using the Google APIs. If so, what you can use is the tokens.list method, that way your will retrieve all the tokens a user has issued to 3rd party applications.
You can use the displayText and clientId values you get in the response to identify the app, and check the scopes to see the permissions of the app.
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 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.
Is there a way to limit the 3rd party applications that can authenticate to a Yammer network? Currently it looks like there are only 2 options, either we restrict any 3rd party applications from authenticating, or we can allow all. Would it be possible for a verified admin to create the application with their own account, and would this not count as a 3rd party application, but rather an internal application?
Thanks!
Disabling 3rd party applications is an "all or nothing" setting. Once this setting is made, all 3rd party applications will be disabled and tokens will no longer be valid between 3rd party apps and Yammer. An alternative in this situation would be for admins to manually send the Data Export to the 3rd party app instead.