I've started publishing videos using Azure Media Services.
The cost of experimenting is reasonable. To start I've added one 30 second video. If nobody watches it, this will cost less than a penny per month. If it receives 1300 monthly views, it will cost only $1.00/month.
My concern is a malicious user who might rack up views. That could cost a fortune in outbound data transfer fees.
So, I need to limit views. I would like a data transfer limit that is both per video and per time frame. For instance, I would like to limit each video to 10 views per hour.
I'm afraid a simple spending limit won't work, because my Azure account hosts other services. Those may need to scale beyond the outbound limit for a video.
You can tryout archive your scenario with Azure Media Services Content protection functionality.
Before user playback video it will get JWT token and video will be configured to use token authentication. Only logged in user or user who get token by solving some simple challenge (captcha or promo code) will be able to watch your video.
Pricing is $0.10 per delivered 100 keys. 1300 monthly users will cost you $1.30.
With JWT token you can cofigure token expiration and have additional logic in your app in regards who will be able to get new JWT token.
Code samples how to configure token authentication can be found in https://github.com/Azure/azure-media-services-samples/tree/master/KDWithADMVC or you can also looked into tests associated with JWT usage in Azure Media services .NET SDK repository (See GetHlsKeyDeliveryUrlAndFetchKeyWithJWTAuthentication test)
Related
I'm working on a website that is supposed to offer users to make use of azures cognitive services api. They can play audio or use their microphone to transform speech into text.
I'm currently using azures js sdk and technically it's working fine. However, I noticed a big shortcoming with this approach. The sdk connects through a websocket with the azure server, which exposes the subscription key to the client. So every member could theoretically read it out and sell it or alike.
Furthermore, if the client connects directly with azure, I have no secure way of preventing clients abusing the service. I need a way to measure roughly how much time a customer uses the service to take into account individual billing.
I could not find anything about that in the official documentation. So what are my options?
Should I redirect the clients' audio input to my own server, do some quantitative analysis, and then forward the input from a server side connection to azure? I fear with many concurrent customers, it might get laggy or connections might get dropped...
Is there any way to attach at least client ids or alike to azure websocket connection that I can read out somehow later?
Do you have any advice for me?
Given your additional comment, I would suggest that you switch your implementation from using subscription key to using authentication tokens.
That would:
generate a unique token for each client, based on 1 global subscription key
not expose your subscription key to your clients
restrict the use of the API, as the token is only valid for 10 minutes
Each access token is valid for 10 minutes. You can get a new token at any time, however, to minimize network traffic and latency, we recommend using the same token for nine minutes.
See documentation here for global implementation. In a nutshell, you need to implement this token generation in your backend, and serve the page to your client with this token instead of the key.
Side note 1: be careful about the maximum number of concurrent requests (100 - see here).
Note 2: that will not help you bill clients given their usage as you have just 1 key and there is no way to identify distinct usages in it
I am confused by the pricing structure for Azure AD B2C defined here.
The question seems to arise from this description:
Authentications: Tokens issued either in response to a sign-in request
initiated by a user, or initiated by an application on behalf of a
user (e.g. token refresh, where the refresh interval is configurable).
In Azure AD B2C settings for my tenant / application, I define a SignInUp policy and then have options for the lifetime of the Access / ID Token (maximum 24 hours), as well as the Refresh token (maximum 90 days) and then the refresh sliding window boundary (up to 365 days or no expiry).
How does this relate to authentications I would get charged for under the authentication pricing?
For example, if I set my Access / ID Token to 24 hours and my Refresh token to 90 days and I use the MSAL library to AcquireTokenSilentlyAsync and I have a user who gets into the app every day, will I get charged 30 authentications for that user per month, or just 1 authentication because the refresh token has not yet expired?
This makes a huge difference in cost and whether I can use B2C for my app authentication needs. For instance at 100,000 daily users, if I only get charged 1 authentication per month, it will end up costing an average of about $50 per month if my Refresh tokens are set to 90 days, whereas if it charges an authentication every 24 hours, I would get charged $6300 per month! Any clarification on this is appreciated.
I received an answer from Microsoft Azure support as follows:
I have reviewed your case and I understand that you have query regarding B2C Pricing. I would like to inform you that, the Tokens issued either in response to a sign-in request initiated by a user, or initiated by an application on behalf of a user. Please find the pricing details as mentioned below:
https://azure.microsoft.com/en-us/pricing/calculator/?service=active-directory-b2c
So if the user or an application, sign-in’s per day one time, hence, it would be charged 30 authentications for that user per month and Also, upto First 50,000 user or an application sign-in’s are free
I sent a follow up for clarification:
So, just for clarification, even if it is the refresh token that is
used (which is good for 90 days if setup that way), that still charges
as an 'authentication'? This makes B2C extremely expensive and there
is no way that the Real Madrid example case is true, as they would be
spending $10,000,000 a year or more just for authentications.
Microsoft will never get indie developers to be able to use this, and
it will be out of the price range of most medium businesses as well.
It is nowhere near competitive with Auth0, which for 50k users a month
and UNLIMITED authentications, costs just $850.
And received the following response:
Your suggestion are really important for us to make improvements for
our product and services. I would recommend that you open the feedback
link and provide us your valuable feedback. All of the feedback you
share in these forums will be monitored and reviewed by the Microsoft
engineering teams responsible for building Windows Azure.
https://feedback.azure.com/forums/223579-azure-portal/suggestions/18796606-lower-the-price-of-ad-b2c
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/10986063-reduce-pricing-for-azure-ad-b2c
https://feedback.azure.com/forums/34192--general-feedback/suggestions/15434943-azure-active-directory-b2c-don-t-charge-for-token
If you look at these feedback, they have not gotten many votes or action in a year, so please, if you want B2C as a viable option for indie developers or small / mid size companies, go vote!
Let me add a few clarifications to the snippet from the pricing site and then explain further.
Revised:
Authentications: ID tokens or Access tokens issued either in response to a sign-in request initiated by a user, or initiated by an application on behalf of a user to obtain a fresh id token or an fresh access token (e.g. when a refresh token is used by the application., where the refresh interval is configurable).
An ID Token has a maximum lifetime of 24 hours. Assuming that you set the ID TOKEN lifetime to 24 hours, a user that uses your application every day for 30 days, will incur at least 30 authentications.
If you set ID Token lifetime to 1 hour, and said users uses your app constantly for 12 hours, then that could add up to 12 tokens in that day.
Conversely a refresh token is "free." Its the exchange of a refresh token for and ID TOKEN that results in an authentication charge.
Jose
Instagram has default API limits for API calls, for sandbox users its 500 and live users its 5000 / hour for an access-token.
Like pictaram.com and picbear.com and other apps, which don't sign in users for getting access token from Instagram, provides services that you can pull data unlimited, for example, in pictaram I search for a hashtag media, normally if we assume that site has own access token which has 5000 calls for an hour can provide 100k images(because one call for tags recent media responses with 20 pictures and next page URL) so you can get max 100k images with 1 access token if you use it for just a tag search but I could manage to get more than 100k media for a tag and the site continued to work like a charm.
How can these sites provides all data without hitting the API limits? They are acting just like Instagram itself.
I am hosting a hackathon at my company and intending on making use of the Spotify WebAPI. I wanted to know what the preferred way of registering apps (does every attendee need a Spotify account or is there some work I can do ahead of the hackathon to have everything ready), as well as notify Spotify of a period of time they can expect a high volume of requests originating from my company's IP.
My planned approach is to have 1 premium account with multiple apps registered (1 per team). Is there a better way to do this?
We deliver social local media products which listen to several different hashtags on Instagram, among others. I'm very much in fear of hitting their API limits, and can't find how to handle many large projects with an Instagram API account.
Right now, I have 5 different clients on Instagram (the maximum), but the problem is if I have 40 projects with 40 separate hashtags each then that is 1600 different hashtags to listen to. If I check each hashtag for new updates every 5 minutes, at 1 API request per hashtag I would hit the hourly limit of the API extremely fast.
How does Instagram want one to handle this sort of thing?
Instagram's recommendation is to authenticate users and use the OAuth per endpoint, since the rate limit for authenticated calls scales as you grow the amount of people using your app.
Why or how it will scale is, the Rate Limit for Authenticated users is per hour per token. So if you have 50 authenticated users, you can make 50 x 5000 = 250,000 API calls before you hit the limit.
From their API Limits Documentation Page: