Page 1 of 1

REST API Not Re-Entrant? 02244398

Posted: Fri Feb 12, 2016 5:58 pm
by jkaashoek
To use the REST API we must log in, using a recent access token. So realistically a new access token needs to be retrieved for every API call, by performing the refresh token operation:

https://auth.bullhornstaffing.com/oauth ... ent_secret}

But what if this operation is done concurrently by two or more users? There is only one current refresh token on the Bullhorn side and any old tokens become invalid by performing a refresh.

Do we need to make the login process/API use single entry to avoid ending up with invalid refresh and access tokens? This is hard to implement on a cluster of servers, and it also affect performance.

What is the strategy for concurrent use of the REST API interface?

Re: REST API Not Re-Entrant?

Posted: Tue Feb 16, 2016 7:29 pm
by DaveNorthCreek
Hi there,

I had to go shovel snow off of my driveway, and that's when I figured out how to respond. This is a REST api, and yes, the OAuth login is cumbersome.

But given a REST approach, you can share the login among lots of servers - the only concern is the login time. There is no conversational state, so here's what I would suggest:

1) Log in on demand via a single login process
2) Share the token among all your servers until it expires
3) Ask for another login when the current one expires.

So treat the login token as a shared resource. Given no conversational state, this approach should provide efficiency and still maintain security - as long as the process of acquiring the token is 'inside the firewall'.

Does that make sense? Too sloppy?

Re: REST API Not Re-Entrant?

Posted: Mon Feb 22, 2016 3:15 pm
by jkaashoek
Thank for thinking about this issue. But asking for a new token could happen concurrently (mutiple requests at once) in a multi-user system and what does that do to the token validity?

Re: REST API Not Re-Entrant?

Posted: Thu Feb 25, 2016 11:25 am
by DaveNorthCreek
I was thinking about this question again for some reason - yes, you could have multiple connection requests. I think you can treat it like a database connection - route all requests from your servers to a single point - perhaps using an internal REST call? - that provides the token.

OTOH, if you have multiple users which have their own username/password combos entered via your UI, would that give you different tokens? I haven't tried that- my use case allowed me to route everything through an 'API' user - but that might be something to investigate. That would give you a unique OAuth session per user.

Bullhorn people, do you have an answer for this?

-Dave

Re: REST API Not Re-Entrant?

Posted: Mon Apr 11, 2016 10:40 am
by SO-BHSupport
Hi Dave and Jkaashoek,

This is Simon from Bullhorn Support and I have been looking into your query about the best way to authenticate REST for different users making the same action at potentially the same time.

So there are a couple of different thought paths we can go down to achieve the same goal, however I think the below are your best options:

1.) Have your calls try use the last session token from a centralised location, if they fail with a "token has expired " message then regenerate the token and update the stored session (to be accessed by all other users till it expires)
2.) Do similar to the above but instead of waiting for an error have another process running every 8 minutes (we time out your token every 600 seconds, so 8 minutes to be safe) to update the centralised location (your code would need to have retry logic so that if the token is expired it will reget the newly generated session)
3.) As an alternative you could have a login portal for your users where you generate an individual session per user (and store this on the server), and then refresh this individual token stopping any cross contamination or concurrent sessions

The reason the last option works is our REST authentication (sessions) works based on the Client ID, Secret and username and password all being unique. If they are all the same it overwrites the session, otherwise it just generates a concurrent session which you can update individually.

Hope this makes sense!

Simon O'Keeffe
Enterprise Support Team Lead
B U L L H O R N
Staffing and Recruiting Software, On Target, On Demand
617-478-9126 (US Support)
+44 800 032 2848 option 1 (UK Support)

Re: REST API Not Re-Entrant?

Posted: Thu Apr 14, 2016 6:31 pm
by jkaashoek
The problem is that we have a cluster of servers so it is hard to centralize the Bullhorn token generation/refresh to exactly one at at time. I am not sure if this is a design flaw or whether I am the only one concerned with this.

Re: REST API Not Re-Entrant?

Posted: Thu May 12, 2016 12:25 pm
by jkaashoek
The access token works only once in the rest login, so what we do now is to refresh the token with every transaction. The rest login returns a rest url and a BhRestToken.

The question is whether this url and token are invalidated when another token refresh happens in the meantime?

To avoid that invalidation scenario we only allow one bullhorn transaction at a time, which is clearly not a high-performance solution.

I am hoping that a Bullhorn expert can give input on this, we'd like to avoid have to experiment with access scenarios ourselves.

Re: REST API Not Re-Entrant?

Posted: Mon May 16, 2016 10:09 am
by SO-BHSupport
Hi Dave and Jkaashoek,

So what invalidates a refresh token/BHRestToken is if the exact same 4 pieces of information are used to generate a new session.

If any of these are different it will not overwrite the current Refresh token, however if they are it will give a "this token has been revoked/refreshed" or similar error when you try use the old credentials.

These pieces of data are:
Client ID
Client Secret
Username
Password

This is why I recommended for a user login page where the user input their Bullhorn username and password, and you can then use this to generate a user specific refresh token and use that moving forwards.

Hope this answers your question.

Kind regards,

Simon O'Keeffe

Re: REST API Not Re-Entrant? 02244398

Posted: Wed Aug 10, 2016 6:48 am
by maryjohn
I was thinking about this question again for some reason - yes, you could have multiple connection requests. I think you can treat it like a database connection - route all requests from your servers to a single point - perhaps using an internal REST call? - that provides the token.

OTOH, if you have multiple users which have their own username/password combos entered via your UI, would that give you different tokens? I haven't tried that- my use case allowed me to route everything through an 'API' user - but that might be something to investigate. That would give you a unique OAuth session per user.

Bullhorn people, do you have an answer for this?