OAuth2 2-legged token


(Chris Hall) #1

Hi,

We’re using the OAuth2 2-legged token asset to provide authentication against an external endpoints that provides data for some of our pages. These endpoints are accessed via Matrix REST Resource assets that use the OAuth2 token for the authentication.

This works fine up to a point. We’re seeing issues when a page has to make requests to multiple endpoints from a single page. If the Access Token has expired, the Refresh Token will be used to get a new one - this is fine until two requests are made simultaneously (or in quick succession) for a new Access Token. The first request will get the new Access Token fine (and therefore a new Refresh Token), but the second request will be trying to get a new Token based on the original Refresh Token (which has now been expired by the first request) resulting in this request failing. Refreshing the page will be successful as both requests are now using the updated Access Token, but this obviously isn’t useful for end users.

We’ve tried removing Refresh Tokens from the response for an Access Token, thinking that Matrix would attempt to re-authenticate each time the Access Token had expired but it doesn’t look to do this - once the Access Token has expired, without a Refresh Token it won’t do anything.

Is there a way of:

  • limiting the OAuth2 Token to trying to only send a single request for a new Access Token (and therefore holding up any subsequent requests until the first request has completed), or

  • getting the OAuth2 Token to automatically try and get a new Access Token based on a certain response from the Authorisation Provider (so that when the second request fails as the Refresh Token has expired, it can try again), or

  • getting the OAuth2 Token to re-authenticate when the Access Token has expired and the Refresh Token isn’t present?

Thanks,
Chris
Matrix v5.4.1.2


(Bart Banda) #2

Not currently, but there might be something that we can develop into the code.

Sounds like this is a race condition and edge case I’ve never seen anyone hit before. It would however make sense for the Oauth token to kinda become “locked” while it’s getting a new Access and Refresh Token and queue up any other requests that are coming its way, I’m not sure how feasible that is though or if that’s the proper way of handling.

Probably something we’ll need to submit as a bug/enhancement request in our roadmap, but the problem being finding an easy way to replicate this so that we can develop against it.


(Chris Hall) #3

Thanks Bart.

We’ll look at alternative ways around this for now then.
Happy to help with replicating when/if you get around to looking at this.

Cheers,
Chris