Flaw in REST API Authentication

[UpCounsel_Devel]

I'm running into a problem with authenticating via the rest API. I run a cron every 5 minutes and every so often I get a not authenticated error. I'm using this ruby client:

GitHub - raszi/mrkt: This gem provides some level of abstraction to Marketo REST APIs.

The problem is that the API includes expires_in in the response with how many seconds left the token has before it expires. Without an exact expiration time, doing something like "Time.now + expires_in" (mrkt/authentication.rb at master · raszi/mrkt · GitHub) is just an approximation.

Even with an explicit timestamp for expires_in though, there is still a possibility of this happening depending on server time accuracy (because my server may not be in sync with the API). This is one why we need a refresh endpoint, or at least a way to force a new token!!

Since I can't force a new token to be returned (AFAIK), I can only handle the error and retry a moment later.

The fact that I'm running the every 5 minutes creates a perfect scenario for this to happen. A new token is created during one run, and ~1hour later intermittently on the 12th run the problem occurs.

Monkey-patching the comparison (in the ruby gem) from "<" to "<=" has made the problem much less frequent, but of course hasn't entirely solved the problem.

[SanfordWhiteman]

Create a second API user and rotate them.

[Anonymous]

Is that common practice to have 2 users and rotate them? Seems like a big oversight in the design of the API auth.

[UpCounsel_Devel]

I also don't see how that's better than just handling the error and trying again. I guess it does save a request, but still seems far from ideal. Especially considering you now have to create another user, and add additional logic to manage the rotating.

[SanfordWhiteman]

Essentially, each API user becomes the other user's "refresh endpoint."   Any architecture has to handle errors anyway, but this is a bit more graceful since errors don't become part of everyday life.  Obviously it's not ideal, but I'm not in charge here!