This thread is for the discussion of the recently released [node:15742, title=“app-only auth”].
First, some quick release notes:
- An application may find repeated attempts to negotiate or invalidate a bearer token made forbidden by a HTTP 403. This limiting is intentional, but the threshold is far too low. We’ll be relaxing these restrictions over the next few days.
- For now, use explicit “id” parameters with /statuses/show and /users/show – interpolated parameters are not yet supported when using this auth format on those methods. This will be resolved in the coming days.
- [node:10280] has been upgraded to work with application-only auth. When accessed with an application bearer token, the indicated rate limits relate to the application-only auth context, denoted by the rate_limit_context/application node that appears instead of the rate_limit_context/access_token node you would find in user-based requests.
- Similarly, X-Rate-Limit-* HTTP headers returned when accessing methods through app-only auth are also scoped to that authentication context
- I wanted to reinforce that the limits assigned to the app-only auth context are completely separate from the limits assigned to user-based auth.
- Rate limits in this context are associated purely with the application. IP addresses are not a factor in per-resource rate limiting in API v1.1.
- App-only auth works only with API v1.1.
- App-only auth requires SSL for all operations. Don’t cut corners. Verify peers.
Let us know if you have any questions or issues working with app-only auth. I think you’ll find it exceptionally easy to implement.