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.
Related
Looking at the Twilio documentation it seems that "you create [Access Tokens] on your server to verify a user’s identity and grant access to client API features."
Here, Twilio provides a few different ways to programmatically create Access Tokens on the Server side - it looks pretty straight forward.
I am developing an Android app-to-app calling feature and for this I've have been using the Android quickstart project to go about it. However, for this code, the implementation and execution are done by copying and pasting Access Tokens generated through either the Twilio Console or Twilio-CLI commands.
Say we have our Server set up, a TwiML app and its associated URL, what would be the simplest and most straight-forward way to generate but then retrieve the access token from the Server to the Client app?
According to me, you would like to access Twilio API using an access token. In that case, you should have a backend server that stores the access token because you shouldn't store such tokens in the client-side. Your app would send request to backend which would then use the access code to access that api and forward you the result back.
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
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.
i will develope a wordpress plugin to access google analytics and visualize the data in a widget. So i checked some existing wordpress plugins, like the famous known "Google Analytics Dashboard for WP (GADWP)" - https://wordpress.org/plugins/google-analytics-dashboard-for-wp/. I was looking for a way how the user authorizes and get refresh and access token to access ga data in behalf of the user (who installed the plugin). And there i found that this plugin (and all other google analytics wodpress plugins) publish there secret. Because in a plugin (which the user downloads) it is impossible (i think) to hide the client secret, because the user of course see's the source code.
As the google documententation describes (https://developers.google.com/identity/protocols/OAuth2WebServer): Important: Do not store the client_secrets.json file in a publicly-accessible location. In addition, if you share the source code to your application—for example, on GitHub—store the client_secrets.json file outside of your source tree to avoid inadvertently sharing your client credentials.
So in this case i think the authentication of the request is lost. If i get or guess a refresh token of any other website that uses the plugin, i will be able to exchange refresh token with access token (because i know the client id and secret) and access the ga data. I already tested that.
So i am looking for a more secure way to access the ga data in my plugin without letting everybody know my secret. Are there any solutions or hints? I thought about sending every request through my server, so nobody know's my secret, but this is also not the solution of the problem. When exchanging the authorization code and receiving the refresh token maybe i have to exchange something like a key pair that will be used to encrypt every following request? Every following request will be to get a new access code for a refresh token.
Of course every user can create his own client id and secret. But this is now very user friendly.
Maybe is it possible to create a new api project and oauth authentication via api (what you normaly do via the google api console)?
Thanks for your help and hints,
Harald
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 .