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
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.
It seems the Google Ads API Client Library (PHP in my case) can automatically handle the access tokens by using a provided refresh token.
Does this mean that the client library will end up making additional calls in order to generate a new access token on every request?
If so, would it be better if I store the access token and pass it with each request and then track when it expires and handle generating a new one myself?
The client library (the Python one at least) does the latter by default. You might want to check if the PHP one does the same.
I have successfully enabled a plugin to work with Azure AD . And based on the documentation I can find, Twilio encourages the idea that if you wanted to communicate from React JS app to custom APIs , then you can do so. The problem I see is that Twilio sort of ignores the fact that when communicating to those APIs from the client app, authentication must be in place between custom apis and react plugin app
How are people unifying the authentication between the Auth that takes place at the UI later and subsequent requests that are mare to backend apis? Can we reuse the token?
Within the https://www.twilio.com/console/flex/users/single-sign-on I see
Does this mean OAuth support is coming? Where can I post this question to increase the likelyhood of receiving some indicators as to which protocols are going to be supported in the near future? If twilio flex team is in fact working on adding OAuth support, I would imagine it would only benefit them to let the community know, especially those with existing microservices and OAuth based flow already preconfigured.
Ive added a issue here hopefully to get some response on this question.
https://github.com/twilio/twilio-flex-token-validator/issues/13
Twilio developer evangelist here.
This is related to the SSO tokens used within Twilio Flex.
You can re-use the token to authenticate your plugin. To do so, you'll need to validate the token from your plugin. You can do this by sending the token to the https://iam.twilio.com/v1/Accounts/{AccountSid}/Tokens/validate endpoint.
This endpoint is currently undocumented and not available within the Twilio helper libraries, which is why you have found it hard to find guidance on this, but here's how you use it.
You need to make an authenticated POST request, using your account sid and auth token (or an API key and secret) to the URL: https://iam.twilio.com/v1/Accounts/{AccountSid}/Tokens/validate
The body of the request should be JSON and contain one key, token, with the value of your SSO token.
The result will be in JSON and if the token is valid will have a key of valid set to true. If it is not, there will be a message field you can read to find more information.
If you are using Node.js, you are in luck as there is a module you can install to do all of this for you; the twilio-flex-token-validator. For more detail on making calls to the validation endpoint, you can check the source code of twilio-flex-token-validator. There is also a tutorial on how to make calls to plugins from Flex that gets to securing the plugin about halfway through.
Sorry it took all of this to get to this answer and it's not the greatest answer. Please let me know if this helps and how you get on.
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.
After reading the documents of Google API. I know that if a project we create needs to access private data, we should use oauth. But here is my situation. we will open a business account in Youtube, and we will create a project to push videos to our own account, we don't need to operate other user's' account. Can we use google youtube data api without OAuth?
There are two ways to access private user data with Google APIs.
Strait Oauth2. where you have a consent for asking the owner of the account if you can access it
Service accounts which are technically pre authorized by the developer.
Normally I would say because you are only accessing the one account that you own, use a service account. Unfortunately the YouTube API does not support service account authentication.
Due to the lack of service account support you will have to use Oauth2. I have done this in the past.
Authentication your script once, using a server sided language of some kind. The Authentication server will return to you a Refresh token. Refresh tokens can be used at any time to get a new access token. Access tokens are used to access Google APIs and are only valid for an hour. Save this refresh token someplace. You will then be able to allow access the YouTube account in question when ever you like.
Note: You will have to watch it. Refresh tokens can on rare occasion become invalid. I recommend having a script ready that will allow you to re authenticate the application again storing a new refresh token. Its rare that it happens but it can happen best to be pre-paired.
Oauth Play ground
Part of the point of Oauth is that it identifies your application to Google though the creation of your project on Google developer console. Things like quota and access to which APIs is controlled though that. If you spam the API they will know and shut you down. (never seen this happen)
When you request access of a user it pops up with the name of the project on google developer console. This is identified by the client id and client secrete for that project on google developer console. When I use oauth playground I get asked 'Google OAuth 2.0 Playground would like to ..'
So by using playground you are using Googles client id and client secrete to create a refresh token for yourself. If N other devs are also doing this the quota for YouTube may be used up in the course of a day. Also security wise you are now giving that project access to your data. Ignore that for a second what if google suddenly decides to remove change the client id or generate a new one. Your refresh token will no longer work. What if random dev X is using it as well and he starts spamming everything and the client id gets shut down (Think this happened last year) your going to have to wait for google to upload a new client id for the one that has now been banned.
Google OAuth 2.0 Playground might seam nice but its not for daily use IMO its good for testing nothing more. Create your own project and get your own access its not hard just requires a programing language that can handle a http Post.
My tutorial Google 3 legged oauth2 flow