We've got a team Slack app and some slash commands configured with them. The slash commands are sending requests to a express REST endpoint which uses passport-slack as authentication.
I want that the requests generated by the slash commands to include the access token for the user since it's already logged in to Slack, but not just the verification token
Any idea on how to achieve this?
I would not recommend this, since it would breach Slack's security architecture and should also be unnecessary if your app is designed according to Slack's standards.
Your app only needs to retrieve and store the user token once during the installation process and can then use it for all future API calls indefinitely, since it does not have an expiry date. They also do not need to be refreshed.
Usually you would install a Slack app only once per Slack team and use that token for all future API calls. This is done using the OAauth 2.0 protocol, which ensured the token is generated in a secure way.
But if you really want the user token from every user, you can ask every user to install your Slack app. Its call "configurations" and that way you get all user tokens. But again, you only need to do that once and you should do it with the Oauth process.
Related
I have developed an express app that's purpose is to send emails. I authorized an email sender using googles oauth2 playground, and their google api. I wanted to use this strategy rather than working with a third party email sender to not be subject to vendor lock-in. I had the system working successfully, but after a day it stopped working with "invalid-grant". In production, I'd like to have a permanent email address (under their google workspace) that is solely dedicated to these bot emails. The oauthplayground says you can avoid the 24 hour expiration, but I recall doing that before and it eventually came up with invalid grant. Is there a better way to set up a bot like this? Or should I just try the oauth playground and using the config panel to avoid the refresh token expiration again?
To start with let me say that invalid-grant means that your refresh token is no longer valid. It is no longer valid because googles oauth2 playground is intended for use for testing purposes only.
Access tokens will expire in less than an hour and refresh tokens created using it will expire in 24 hours.
While it is possible to configure it to uses your personal client id and client secret it is still not the optimal way to go
Even using this method for production is not going to work well for you. If your app is still in testing phase then your refresh token is goin to expire in seven days. You will need to set your app to production in order to have a refresh token that does not expire.
The issue then becomes that in order to use the gmail api your going to need to have your application verified. You can not verify your application using the googles oauth2 playground as a redirect uri as you can not verify that you own this domain.
The solution to your problem is to create an application of your own hosted on your domain. This will allow you to create the credentials you need and have your app verified by google.
under their google workspace
You made one comment that is not clear. If you are using google workspace then why not just set up a service account with domain wide delegation to the user on the domain. You will avoid all the issues you are having above.
Do I still need a backend to generate access tokens for Twilio video?
Twilio's programmable video documentation talks about the client-side room creation option which can let us "get up and running without writing backend code".
https://www.twilio.com/blog/2017/04/programmable-video-peer-to-peer-rooms-ga.html
I know the testing tools let us create temporary access tokens, but those expire in 4 hours, making my Twilio demo stop working unless I'm refreshing tokens manually.
The reason behind handling access token creation on the backend is you can wrap the appropriate authentication methods around the recipient requesting the access token and make sure the API Keys to create those limited access tokens are secured.
For demo purposes, you could possibly look using the Twilio-CLI to create an access token with a longer expiration (up to 24hrs) or possible write a Twilio Function to handle this (with the understanding that you would not have a method of authenticating the clients requesting a token and assigning the appropriate identity, so there is risk).
Twilio CLI Plug-ins
"twilio token plugin: Install and use this plugin to generate a token for use in a client-side SDK, e.g., a chat application."
https://www.twilio.com/docs/twilio-cli/plugins
I want to make an alert system on Apigee that will automatically send alerts to Slack, without the need for human interference.
However, the only OAuth flow for Slack I found on their api site seems to require a user to manually input their credentials: https://api.slack.com/docs/oauth
How can I automate getting an access token from Slack, so without having to manually input credentials?
I think you may have misunderstood the concept of Oauth. The way it is supposed to work is, that you run the process only once per Slack team (usually while installing the Slack app to your Slack team) and then store the access token you received for future reference (e.g. in a database). So whenever your Slack app needs the access token after installation it can always reuse the one it received during installation.
If you don't require any scripts to run for installation and you only need the access token you can also install your Slack app directly from Slack (under "Your Apps") and then copy and paste the resulting access token to your app configuration. Check this documentation for further information.
If you are generating webhooks on the fly, it requires OAuth 2.0 each time. However, if you use the Web API chat.postMessage method, it only requires the token (under the OAuth & Permissions section) to make a HTTP POST request to send a notification.
Goal
Fetch a company's updates save them locally in a background task
Problem
This should be done as a backend service without any real user interaction. We could provide a user account to use, but the authentication is a problem: There is literally no one to answer the OAuth redirect and there is no public redirect URL to configure, since it's a background service.
Is there any way to access the API without having a redirect URL or a real user?
You can get an initial access token in a regular front end flow, for you as the app developer i.e yourself as the LinkedIn user. Once you've got that, you can store it in the backend and use it for 60 days to get access to the LinkedIn APIs.
After 60 days you need to refresh the token as documented in:
https://developer.linkedin.com/documents/handling-errors-invalid-tokens
Unfortunately LinkedIn does not (yet) support an autonomous refresh flow where your app can get a new access token by presenting a refresh token on a backchannel. So the developer will have to refresh the access token by a manual login every 2 months.
Well, it is still all HTTP and HTML, so in fact there is no real reason to show the OAuth dialog to a user, as long you can strip out the necessary parts in the HTML authentication dialog and send a valid response back to the server, using the username and password from the user (which you can obtain from him, or save it yourself in a config file if it is you).
Note that there might be a legal issue if LinkedIn demands you to actually show the dialog, beside that, there is no technical need.
Trying to test installation process for my marketplace application. Google documentation says that I can test installation process by using Test Install Flow button in the console. When I click on that button, I see the authorization dialog and I click accept. The dialog is closed and app is installed on the domain I am testing.
Question: Should I be getting and storing a refresh_token at some point in this installation process?
There is an Install URL that I can specify in Drive SDK but I can't find documentation about when Google posts to this install URL and what gets posted.
Here is a project which shows you how to do just that:
Checkout the section called: Cached Credentials
http://www.codeproject.com/Articles/488185/Working-with-Google-Drive-in-WPF
Excerpt from the above URL:
Provided the user allows access, the authorization server will return the authorization code. It can be sent back either by the Google server calling a web service endpoint opened by your application or in the title of the page sent back to the browser. Because of the challenges of spooling up a web server, opening a connection through any possible firewall(s), etc... it is much easier for installed applications to simply scrape the authorization code from the title of the resulting web page. That is the technique used in the sample project. If successful, the title will be set to Success code=xxxxxxxxx where the xxxx's are replaced by a unique authorization code.
The authorization code only gets you invited to the party. You can't do anything with that code as far as API access. The Authorization Code must be exchanged for a short-lived access code and a long-term refresh code. In the Google.Apis.Authentication.OAuth2 library is a class called NativeApplicationClient. This is the wrapper for the authorization server and it has a method called 'ProcessUserAuthorization'. This method takes the authorization code we retrieved after the user authorized the application's access and turns it into the access token and the refresh token. The access token is what we actually need for the task at hand and it is maintained in the NativeApplicationClient. It gets passed with all subsequent API calls. The nice thing about the NativeApplicationClient is that it knows how to verify the access token and how old the token is. If the token has expired, the client will use the refresh token to get a new access token. That takes the burden off of us to manage token lifetimes.
The short answer to your question around the refresh_token is - No. You won't get a refresh token upon install. You have to instead ask for a fresh access_token using a Service Account key you've got.
So basically, the way a Google Apps Marketplace (GAM) app is supposed to work is to get itself a Service Account and build with that for all authorization. There are no refresh_token with Service Accounts, just fresh new access_token. For an app that is installed by consumers you should use standard web server flow. This is one area of complexity that wants to be both a consumer and enterprise app.
When an admin installs your app, he/she is in essence authorizing your app's Service Account key to his/her domain.
Once an app is installed, that Service Account has full delegated access
Regarding the Install URL for a Drive app. You can ignore that for a GAM app.
Hope this helps. We'll release some end to end sample at some point soon .