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
Related
I have an android app for the client app and the express for backend server.
Let's say an authorized user got a token with 8 hrs expiration time. So after 8 hrs, the user would need to log in again.
My problem is that when an authorized user login in different devices one after another,( like 7:00 AM on the old device and 8:00 AM on new android device), at that time, from a web server, I want to give only 7 hrs expiration token to the new Android device.
To sum up, I want each login users to share the same token to syncing with even if they login multiple devices.
P.S. As this's my first question on SOF, I don't know how to ask good questions properly but I'll try.
I would assign the token along with the date it was created to the user id.
So when the user logs in, you receive an user ID (it could be the email for example) and you reply to the client with the associated info (token and date), of course, in here you need to do some extra checks such as check token expiracy, check if the user id was logged in before (on some other device as you said), but you get the point.
You should keep this information in the database or in some in-memory system such as Redis (depending on the quantity of users the application has).
Is OAuth API call counted as API request? As you know, the number of API request call is limited to 1,000/account/hour. My customer would like to know whether OAuth API call is included into its limit or not. I coudn't find out any information regarding this topic.
Their developing application now can't keep holding access token after an envelope process is completed. It will be fixed later but at present, OAuth API call happens whenever end-user sends an envelope through their application.
Therefore, they want to confirm this point.
I don't know offhand if OAuth API calls count against the limit. If they don't currently then they will in the future.
All software stacks for web apps include a session storage feature which should be used to store the access token returned from the OAuth process.
In addition, note that your understanding of the API usage limits is not correct. The limit is 1,000 API calls per Integration Key per account per user per hour.
For example, if Joe and Susan are using the same Integration Key (same application) and they both use the same account on DocuSign then each of them can make 1,000 API calls per hour.
As I understand it, Instagram may expire our access tokens after an arbitrary period of time, in which case 'API responses will contain an “error_type=OAuthAccessTokenError”'.
Is the only way around this to get users to log in again?
I'm building an Instagram service which helps brands manage their following, and every day at a set time we request for their pictures and comments to run data analysis on engagement rates. Does that mean that we might arbitrarily lose access at any time and not be able to restart our service to our clients till they log in to authenticate again manually?
Any help with renewing Access Tokens would be appreciated!
You should verify if the initial grant included a refresh token in the authentication response. If not you may need to reauthenticate after expiration I think.
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)
How to increase following limit per hour on Instagram? is there any other ways to increase following peoples more than its limit.
Can we increase by using multiple application?
If you ask your users to log into their Instagram account, and authorize your app, then you can make 5000 requests per hour per user:
http://instagram.com/developer/limits/
If you just use your key, you are limited to 5000 requests per hour, no matter how many users you have.
But I'm worried, what if this token expires?
AFAIK, Instagram accesstokens don't expire currently.
Note: From Instagram documents.
Note that we do not include an expiry time. Our access_tokens have no explicit expiry, though your app should handle the case that either the user revokes access or we expire the token after some period of time. In this case, your response’s meta will contain an “error_type=OAuthAccessTokenError”. In other words: do do not assume your access_token is valid forever.
Should I authorize the app each time the token expires?
At the moment, you do not need to do that, as token does not expire. As and when the token expires in future, a corresponding warning or error code and message will be sent to you, which you need to handle.
what can I do to have my app always pulling data from account without
my participation?
You can try following:
Use sharedpreference to store the accesstoken.
First time when you try to fetch data that needs accesstoken(Authenticated requests), first check in the sharedpreference whether the accesstoken is stored or not.
if yes then you don't need to login, just use that accesstoken. If you don't have the accesstoken in preference then do the login using instagram credentials, get the accesstoken and then share it in shared preference and use that for subsequent requests.
You can provide instagram logout option in which you just need to clear the accesstoken from sharedprefernce.
Hope this is helpful to you.