Avoid concurrent renewal of last mile token

I'm currently looking at the oauth renewal example from the Last-mile security:

https://github.com/apigee/api-platform-samples/blob/master/sample-proxies/outbound-oauth/apiproxy/pr...

I wonder what happens if the token expires and there is a large number of concurrent requests that all find the token cache empty. Do they all renew the token at the same time? This would cause quite a bit of traffic. How to ensure that only one request renews the token?

Is there a way to schedule the token renewal?

thanks

0 4 351
4 REPLIES 4

a large number of concurrent requests that all find the token cache empty.

How would this happen?

Presumably there is a single client instance that "owns" the token. Are you saying the client instance is highly concurrent, and issues lots of requests in parallel?

In that case I suggest you tell the client to serialize the calls for a new token.

The client is a web app that is used by many users within an organization. So I can't serialize the requests.

Furthermore, this is about last mile security so preferably I want to share the token caching with many apps within the same organization. That's another reason why the requests can be highly concurrent.

You need to consider how that web app manages tokens. There are two common approaches:

  1. per-user tokens
  2. one token shared across all users

In the first case, per user tokens... Within the web app, there's some state that is kept for each user, a context. Maybe it's tracked via a cookie. The token needs to be attached to that state. Tokens are per-user. N users = N tokens. You CAN serialize the requests for a given token (= user). That solves the problem. The web app can be concurrent and can handle thousands of tokens...

Maybe you have the less common case, in which you share a single token across all users. If you want to use a single token in the web app for thousands of users, then I will revert to my prior statement: the client (web app) needs to manage the concurrent access to that token. This is a necessary conclusion from "I want to share a single token across 1000's of users." It is inevitable.

so preferably I want to share the token caching with many apps within the same organization.

I don't know what you mean by "share the token caching". If you mean "share the cached token" the answer is no, don't do that. Do not share tokens across apps. Every app gets a token. If you mean "share the approach of managing tokens" that's fine, and there's no obstacle to you doing that. That's just client code that you manage, and it will look different depending on whether you go with option #1 or #2 above.

I think we talking about two different things :). I am interested in last-mile security, i.e. I want to enforce that only apigee can make calls to the backend api. The way that we doing it currently is that we let apigee fetch a temporary token for accessing the backend api. This means all apigee calls (wherever they come from) are indirectly using this backend token on the last mile. This is purely on the apigee side and is transparent to the web apps.

We achieved that by having a nodejs daemon running on apigee that renews the backend token and puts it into the apigee cache. However, this seems to be deprecated and I am looking for an alternative solution.

The problem with the solution from the docs is that multiple concurrent calls can trigger multiple token renewals. However, the token should only be renewed once.


What I can do is to have a last mile token for each app. This is probably good enough and would not trigger to many concurrent token renewals. Enforcing serialized access to the API because of apigee internals seems to be not a good solution. Any other ideas/comments are welcome!