Samantha Andrews and Kristo Jorgenson identified a race condition in use of  the http_basic_auth_token endpoint, which generates a new bearer token every time you hit it. If you've got multiple threads making HTTP requests, you're liable to get multiple hits to that endpoint around the time a token expires, since each thread will discover the expiration simultaneously. Since only one token can be valid at a time, this means all but one thread will end up with an invalid token and the process will repeat.

A simple solution is to change basic_auth_temp_token so that it returns the existing token (instead of creating a new one) if the token a) has not expired, b) was created recently. I think this means using Credential.lookup_by_patron to find an existing token, and then using temporary_token_create (as you do now) if you need to create a new one.

For now, let's say "recently" means within the past 60 seconds.

On the server side, this is less simple than it seems, since we don't store the creation time of a Credential. However, we do store the expiration time, and we know the lifetime of a Credential (one hour), so basic math will give us the time it was created.

Note that you'll still need to wrap the inner token with the provider name before sending it out over the wire, whether you created a new one or ended up reusing an old one.