I'm making a Slack App and just implemented OAuth to take advantage of Slack's Web API. I am using the single Access Token for my particular team that I am testing on.
Should I want to distribute this app on the Slack App Directory, will I have to store the Access Token for every single team? How should I go about securely storing these? Will the Heroku database suffice?
Yes, your app needs to store the access token for each Slack team that installs it. And your app will need to access those tokens in order to enable access to that team's Slack (e.g. post a message). Most people will use a local database (e.g. MySQL) on the server to store the access tokens of each team.
No idea how secure the Heroku database is. However, since Heroku is a commercial service I would assume it can provide sufficient security for your app.
Related
I am trying to make a desktop application with Twitch API and Google API.
Since this application requires Twitch user permission, a user needs to authorize my application through twitch's OAuth and I think there's no way to omit this process.
Now, I want to add some functionalities from Goole APIs, for instance TTS.
My application will be installed and run on user's local machine,
it cannot store API key or credential information safely.
I think I have three options:
Add Google OAuth: This is most safe way, I think, but I don't think I can convince users to authorize another Google account even though they already authorized their Twitch account.
Make a kind of proxy server which verifies request for Google API using twitch authentication information and relays request to/response from Google API. This seems feasible but it requires additional payment to running server for sending data from Google API. I already have to pay for TTS service, another payment for proxy server which sends binary data frequently would be a financial burden for me.
Make a server to acquire API key for Google API. This also requires additional server, but it does not involve lots of traffic because application will access Google API directly once API key acquired. However, I concern that the API key may be easily stolen using monitoring tool such as wireshark.
Which method should I use here, and how can I improve it?
Or, is there better way for this case?
My Azure App's client secret expiry was set to 3 months which has expired and the application has stopped. My questions are:
How can I get the new client secret to the same Azure App to
replace the new client secret in my NodeJS application?
Also is there a way to get a warning or message/mail before the client secret expire?
How to check the expiry of client credentials without using the Azure portal( that is by using REST requests if any)?
Screen Shot showing expiry in Azure portal. Can we get this expiry somehow by REST requests?
How to check the expiry of client credentials without using the Azure
portal( that is by using REST requests if any)?
You should be able to use Graph API to get this information. The operation you would want to invoke is List applications which will give you a list of application objects. The property you would want to check is passwordCredential for credential expiry.
Also is there a way to get a warning or message/mail before the client secret expire?
AFAIK, there is not an automated way to do this. I believe I read somewhere that Graph API team is working on it but there was no ETA provided for this by them. For now you have to roll out your own solution. You may write a timer-triggered Azure Function which runs daily. This Function can get the list of applications and filter out the applications credentials for which are expiring soon and take action on that.
How can I get the new client secret to the same Azure App to replace the new client secret in my NodeJS application?
Based on your comment, considering you are currently doing this process manually so I would assume you can continue to do so. Once you know that the secret is expiring soon, you can create a new application secret and at appropriate time replace the old secret with the new secret.
I'm trying to figure out how to migrate a system that is currently using ACS to Azure AD. I've read the migration docs provided by Azure and have looked through the Azure AD docs and the sample code but I'm still a bit lost as to what the best approach for my situation would be.
I've got a web API that has about 100 separate external systems that connect to it on a regular basis. We add a new connections approximately once a week. These external systems are not users--these are applications that are integrated with my application via my web API.
Currently each external system has an ACS service identity / password which they use to obtain a token which we then use to authenticate. Obviously this system is going away as of November 7.
All of the Azure AD documentation I've read so far indicates that, when I migrate, I should set up each of my existing clients as an "application registration" in Azure AD. The upshot of this is that each client, instead of connecting to me using a username and password, will have to connect using an application ID (which is always a GUID), an encrypted password, and a "resource" which seems to be the same as an audience URL from what I can see. This in itself is cumbersome but not that bad.
Then, implementing the authorization piece in my web API is deceptively simple. It looks like, fundamentally, all I need to do is include the properly configured [Authorize] attribute in my ApiController. But the trick is in getting it to be properly configured.
From what I can see in all the examples out there, I need to hard-code the unique Audience URL for every single client that might possibly connect to my API into my startup code somewhere, and that really does not seem reasonable to me so I can only assume that I must be missing something. Do I really need to recompile my code and do a new deployment every time a new external system wants to connect to my API?
Can anyone out there provide a bit of guidance?
Thanks.
You have misunderstood how the audience URI works.
It is not your client's URI, it is your API's URI.
When the clients request a token using Client Credentials flow (client id + secret), they all must use your API's App ID URI as the resource.
That will then be the audience in the token.
Your API only needs to check the token contains its App ID URI as the audience.
Though I want to also mention that if you want to do this a step better, you should define at least one application permission in your API's manifest. You can check my article on adding permissions.
Then your API should also check that the access token contains something like:
"roles": [
"your-permission-value"
]
It makes the security a bit better since any client app with an id + secret can get an access token for any API in that Azure AD tenant.
But with application permissions, you can require that a permission must be explicitly assigned for a client to be able to call your API.
It would make the migration a tad more cumbersome of course, since you'd have to require this app permission + grant it to all of the clients.
All of that can be automated with PowerShell though.
We are planning a Slack app but we need local storage, we do not want to store any data of user/channel at our server, we want to save it permanently or temporary on local machine of user or in Slack server.
Is there anyway to do it?
Thanks
Here are my thoughts on the topic:
Local storage solution
You would need to implement a "local" helper-app that every user needs to install. Keep in mind that Slack works on many different platforms. So you would either need to limit your app to certain platforms (e.g browser only), or develop a "helper-app" for all platforms that Slack is currently supporting (e.g. Browser, Windows desktop, Apple desktop, iPhone, Android).
You would still need to host your Slack app on a server. Slack requires you to provide a fixed URL to connect to your Slack app, e.g. to invoke a slash command or after pressing a button. Your app would then need to manage the connection with the local helper-app to access the local data storage.
So, I guess it would be technically possible, but would require a lot of effort. And since you will need to host your app on a server anyways, it might be more feasible to also put your user data there.
Storing data on the Slack server
It is possible to store user data on the slack server through the user profile. There one can add custom key/value pairs through users.profile.get and users.profile.set
However, this will not work for slack team related data, like the individual Slack token that is received during the app installation process and needed by the Slack app to use those API methods. So your app needs to at least store the app token centrally together with the slack app itself.
We are trying to put an app on the marketplace which needs multiple client_ids
(The app is running on appengine standard with python 2.7)
a client_id for the service_account with domain wide authority
a client_id for the web application
a client_id from an apps-script library
All client_ids use different scopes. I have combined all scopes and entered them on the marketplace SDK configuration.
When i deploy the app on a test domain, only the serviceaccount seems to be authorized.
When the user then access the webapplication he is presented a grant screen which we want to avoid.
The documentation https://developers.google.com/apps-marketplace/preparing?hl=fr seems to imply that multiple client_id's are possible.
How should i configure the marketplace app so that multiple client_ids are authorized?
Is there something special i should do on the credentials configuration page of the api-manager?
Check how you implement the authorization using OAuth 2.0, Service accounts allow a Google Apps domain administrators to grant service accounts domain-wide authority to access user data on behalf of users in the domain. You can also read Server to Server Applications documentation.
Note: You can only use AppAssertionCredentials credential objects in applications that are running on Google App Engine or Google Compute Engine. If you need to run your application in other environments—for example, to test your application locally—you must detect this situation and use a different credential mechanism (see Other). You can use the application default credentials to simplify this process.
Hope this helps.
It turned out all three client_id's were being authorized after all.
the days that i was testing this, it took very long for the authorization to take effect.
At this time all scopes and clientid are authorized within a few minutes.