Authentication Design for Long Running Processes
The Use Case
In some circumstances, a service A is invoked by an end user, X. In order to fullfill the request, service A must make additional API calls to services B and C. We want to avoid issuing powerful service-level identities when possible. OSDU convention is that API calls should be authorised with the end-user’s permissions whenever possible, thus Service A must invoke Service B using the user X's
access_token. For interactive sessions this is fine. Service A can cache the
access_token of user X. When invoking services B and C, service A can transmit user X’s tokens.
Why We Need Long-Running Sessions
In some cases, the time required for service A to complete the work will be longer than user X's tokens are valid. The total execution time might take hours or even days. Subsurface data is huge (terabytes, petabytes) and some of the operations (training machine learning models, building maps, etc.) take a long time to complete in wall-clock time, regardless of the CPU horsepower available. Thus, service A must maintain access to user X’s identity, in order to call services B and C repeatedly over the duration of the job. JWTs have a fixed expiration time established when they are issued. The tokens cannot be used beyond that expiration time and they cannot be extended. The OAuth standard allows new tokens to be issued to continue a session.
Long running processes will need to be able to remain authenticated while accessing resources. A strategy for timeouts of access tokens and refresh tokens needs to be determined that remains secure.
A few ideas
1. Token Caching Service
A centralised system can cache tokens for logged-in users. Service A can register it's tokens with the TCS and get tokens renewed by the TCS as and when it needs new ones. Getting the refresh token from the user is not normal, but it is possible.
2. OAuth Client ID/Client Secret
Users can authorise an application via the OAuth code mechanisms to operate on their behalf.
Both 1 and 2 are unnecessary if we use
private_key_jwt authN for the service account, allow longer lived tokens for service accounts, and enjoy the benefits of a
refresh_token to obtain a new
access_token's can be opaque to protect them in memory. And long running processes only need an
access token if they are calling other API's that require service authentication. See #37 (closed)