Allow usage of z/OSMF JWT tokens by multiple sessions using the same user ID

We are using new APIs to obtain JWT tokens (/zosmf/services/authenticate) from our automated scripts that use other z/OSMF REST APIs with the obtained. After the script completes, it calls the DELETE method to invalidate the token that it obtained. When there are multiple scripts running at the same time or a person using a web UI with the same credentials, the DELETE method or logout will invalidate all the sessions and the scripts fail.

It seems that the JWT token that is returned for the exact values of user ID and password are all always the same so the logout (DELETE) done by the client, invalidates tokens that other clients have. It prevents reliable programmatic usage of z/OSMF REST API from programmatic API clients because the token obtained by one client can be invalidated by another one. It seems as unexpected behavior since using a different case (e.g. “uSeRiD” or “USERID “ instead of “USERID”) or different PassTickets leads to different JWT tokens that are not invalidated by the DELETE method on other JWT tokens for the same user.

The requested behavior that is present in other software that generates JWT tokens is to generate different tokens for each login request (i.e. each session).

Since the tokens are used from independent sessions (different script, or web UI), we would expect that the POST /zosmf/services/authenticate will return different tokens for different sessions and the DELETE will delete just the token for one session. The expiration should be the configured duration from the moment of the request.

We agree that there can be a use case to invalidate all tokens of a user. The current behavior does not achieve that since tokens.

The expected behavior (different tokens for each POST request) is important for using REST API programmatically from multiple applications at the same time. Current behavior makes the usage of JWTs problematic because they can be invalidated at any moment by another application that is using them.

There is no good workaround for the problem. If the script does not use DELETE itself, there can be other scripts that call it.