Here http://developer.twitter.com/pages/rate-limiting we can read that:
Anonymous calls are based on the IP of the host and are permitted 150 requests per hour. This classification includes unauthenticated requests (such as RSS feeds), and authenticated requests to resources that do not require authentication.
OAuth calls are permitted 350 requests per hour.
And as we can see at http://dev.twitter.com/doc/get/users/show - it does not require authentication.
So I expected my localhost will reach limit of accessing users/show/zerkms endpoint after 150 requests. But I was able to perform all 350 requests.
Where is the truth?
If you are sending authentication headers to Twitter, then your rate limit will be the authenticated rate limit of 350 requests to rate limited resources per hour, and this is regardless of whether you are calling methods that do not require authentication.
So, since you were authenticated, you had 350 API calls you could burn. If you were unauthenticated, you could only have made 150 calls.
Edit:
I believe the documentation you specify is indeed incorrect. Authenticated requests to resources that do not require authentication, are not subject to the unauthenticated rate limit. Rather they are subject to the rate limit restriction of the currently authenticated account.
For example, if I make an authenticated call to users/show (a resource that does not require authentication) the rate limit headers on the HTTP response show X-RateLimit-Limit: 20000, X-RateLimit-Remaining: 19999. If I then make an unauthenticated call immediately to users/show, my rate limit headers show X-RateLimit-Limit: 150, X-RateLimit-Limit: 149.
There's a difference between requiring authentication and supporting authentication. If you provide authentication, in most cases, the Twitter API will consider it an authenticated request. If you want to ensure that your request is evaluated unauthenticated, don't send authentication.
I think it's related to http://dev.twitter.com/doc/get/statuses/followers and the old 'basic auth' because it starts with "depending on the authorization method" (even though there's only one method nowadays?). It doesn't require authentication but in some cases it does.
To make developers move to OAuth, they increased that rate limit when an API call is done using OAuth; that's what the second statement says.
Related
As we can see here: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par#section-2.2
pushed authorization request lifetime should be between 5 and 600 seconds.
So assume that it's 60 seconds. Then client redirects user to authorization endpoint and... user is not logged in. So authorization endpoint redirect the user to endpoint with login page with request_uri as query param. The user logs in, login page redirect user to authorization endpoint with request_uri from query param. Probably, if lifetime was about 10s the request_uri is expired now (and what's more it's used more than once). So how can we handle the flow when user is not authenticated while he is redirected to authorization endpoint and we use PAR?
I know that can be 600 seconds also, but the recommendations say that this lifetime should be as short as possible. Therefore, it seems to me that I misunderstand how PAR works. I don't think even 10 minutes is enough because what if user currently doesn't have account at the identity provider or there is MFA used?
Please tell me, how PAR really works.
Consider a browser based app implementing this flow:
STEP 1
The browser wants to begin a login and calls its backend. The backend sends a standard Open ID Connect request like this to the authorization server:
POST https://login.example.com/oauth/authorize/par
Authorization: Basic czZCaFo3RmpmcDBa:QnIxS3REUmJuZbUl3
client_id=myclient&
redirect_uri=http%3A%2F%2Fwww.example.com%2F&
scope=openid%20profile&
response_type=code&
response_mode=jwt&
code_challenge=WQ4Y4CQpO8W6VtELopzYHdNg&
code_challenge_method=S256&
state=NFBljlVuB1GDjgGARmqDcxtHhV8
The authorization server saves the OIDC request details. Note also that the authorization header includes the client secret, which is one of the key features of PAR - the client authenticates before the redirect to the authorization server. So a malicious app cannot redirect a user with your client ID, since they do not know the secret.
STEP 2
The browser then uses the request URI. The short time you mention is only for this redirect and does not impact user login time:
https://login.example.com/oauth/authorize?
client_id=myclient&
request_uri=urn:ietf:params:oauth:request_uri:7d353fc8-9b94-488f-8c61-cf7cc1dfef9e"
STEP 3
The user logs in, and in some cases that might take a minute or so, as you say. Then a response is returned to the browser:
https://www.example.com/callback?response=eyJra...
In this example I am receiving the response as a JWT, using a related standard called JARM that can be used in conjunction with PAR. The JWT looks like this and could contain an error response in some cases:
{
"exp": 1629112321,
"iss": "https://login.example.com",
"aud": "myclient",
"iat": 1629112301,
"purpose": "authz_response",
"code": "abcdef",
"state": "12345abcdef"
}
If you don't use JARM you will instead receive code, state and error fields in the browser URL. The flow finishes with the usual authorization code grant POST, to swap the code for tokens.
SUMMARY
All of the above is designed to prevent man in the browser attacks. Eg a malicious party cannot alter any fields in flight. Extra security is therefore added to the standard code flow.
We have implemented a central token store for making multiple Podio API requests from AWS Lambda using the same access tokens. I have been seeing frequent "unauthorized" exceptions returned from Podio. When I use the token from the "unauthorized" request directly in REST Client it works fine. In addition, the rate limit values show that I am not near the limit. Is there a limit to the number of concurrent requests in Podio by account? Thanks for any help.
If Podio returns 403 Unauthorized then access token you've provided is not valid for resource requested. And there is no way that same request for same resource with same access token that got 403 once will get successful response when you run it from another client.
If you want to troubleshoot it well: record/log full https request and response.
Regarding rate limit part of your question: there is different limit for login operation. And there is no general limit on number on concurrent requests by account, but load balancer and DDOS protection might kick in if you go insane.
I've got an OAUTH2 Authentication Server which set a default TTL (3600s) for every new acccess_token.
But in my opinion the access_token TTL should be different for every Resource Server.
Like for a JavaScript Webinterface it should be 3600s, for an Android App it could be one month.
Who decides how long the access_token TTL should be?
Should the GET access_token request from the Client request a custom TTL?
Should the TTL for every Resource be defined in the Service Configuration (along with client_id, client_secret, App Description, ...) on the Authentication server?
The Authorization Server that issues the token is responsible for assigning an expiry time to it. There's no standardized authorization request parameter that the client can use to indicate the preferred TTL. The Authorization Server decides based on a policy that may be based on the client identifier and the associated/configured "permissions" or "trust", parameters available in the Authorization Request (e.g. scope) and other contextual data like HTTP request parameters, time of the day etc.
On the twitter Rate Limiting page(https://dev.twitter.com/docs/rate-limiting) it says
"Unauthenticated calls are permitted 150 requests per hour. Unauthenticated calls are measured against the public facing IP of the server or device making the request."
Is that the measurement based on enduser IP address or the server IP(ip of http:xxxx.com) ?
Is there a way to increase the limit may be through some paid service of Twitter ?
Regards,
Navin
Server IP
No. But you should use authenticated calls (oAuth) - you get 350 requests per hour. Each authenticated user of your app has 350 calls you can use, IP ignored.
How do I implement the oauth_token into my request?
When making a request to twitter's REST API:
https://api.twitter.com/1/users/show.json?screen_name=shakira
I get the rate limit error (Rate limit exceeded. Clients may not make more than 150 requests per hour.)
I have created a twitter application and received an access token, which I am now trying to use to boost my rate limit to 350. I have tried adding it to the url, like so:
https://api.twitter.com/1/users/show.json?oauth_token=MyAccessTokenGoesHere&screen_name=shakira
But that isn't working...
OAuth parameters should go to the header of your request, not in the URL. For more details check the following article in the documentation:
https://dev.twitter.com/docs/auth/authorizing-request