Reaching the /admin/rest/um/1/user/ endpoint after session authentication is depreciated

[Perry Ravet]

With the upcoming depreciation of session based authentication, how does one recommend making a rest call to the /admin/rest/um/1/user/ endpoint to retrieve user information? Specifically, I am looking to get the productPresenceList   response  of a user query programatically to keep track of last activity dates.

[Daniel Eads]

Hi Perry,

You should be able to just replace wherever you're inserting a password with an API token that you generate from the web interface. The advantage of tokens is that they can be revoked individually without having to change the password on the account. You can use different tokens in different applications and they won't affect one another. You can also see the last time each individual token was used.

Check out our KB article on creating and using tokens. For most scripting languages, you should be able to just paste in a new API token to where you've currently got a password saved.

Cheers,
Daniel

[Perry Ravet]

Daniel,

While I am aware of token based authorization, it appears I am unable to make a call to any /admin/rest/um/1/user/ endpoint without a valid cloud.session.token. Attempting calls to this endpoint using token based authorization always returns a 401 status and a return body of "User failed to authenticate"

[Daniel Eads]

Hey Perry,

I can confirm that I'm also seeing 401's to that endpoint despite the same token working elsewhere for other calls. I've reached out for some more info about this endpoint as it's not documented, which means it's not supported. My guess is that at some point this was posted as an experimental API but then pulled from public view, or that it's always been a private API endpoint that someone reverse-engineered. Given that we're constantly working at reducing security exposure, someone could have easily decided to not extend token-based authentication to that endpoint since it probably wasn't public to start with (and the cookie/password based authentication is about to be pulled).

Since it's not public, there isn't an onus on the developers to "fix" it so that tokens work. I can see how that's frustrating as the info at that endpoint would be really handy to identify inactive users and recover their licenses. Furthermore, there aren't any Cloud add-ons in the Marketplace that help identify/deactivate inactive users, making it a super bummer.

As a workaround you can manually sort the list in the UI (described in this article). Not as slick as a script but it looks like it's the only option once that undocumented endpoint goes fully private.

Daniel

[Perry Ravet]

Daniel,

Thank you for your reply. To give more clarity, this endpoint is the same one that Jira User Management page is calling to gather its data in the web browser via the UI. I am simply trying to recreate its actions via rest call. Ex: Going to the https:<mydomain>/admin/users/ via administration panel will call :

• Request URL: https://<mydomain>/admin/rest/um/1/user/search?max-results=30
• Request Method: GET
• Status Code: 200

I am simply recreating that call via rest client.

In the past, this call required a session token created to work, and that is what was used.

I just want to be proactive in that a bulk of automation will go down due to not having a proper replacement for these endpoints.

[Daniel Eads]

Hey Perry,

I've just been in touch with the Atlassian ID development team. They've re-iterated that the endpoint is not a public API.

They also said that you could continue using it if you generate session tokens manually and respect any updates to them via Set-Cookie headers (although programatic acquisition of session tokens is being phased out). That's not to say it couldn't get pulled out from under you in the future though.

You could raise a feature request on jira.atlassian.com for a public endpoint for this. For more information about how Atlassian prioritizes feature requests made on jira.atlassian.com, check out this Community post.

As another semi-option, you could also grab details from the User Export. Still not as nice as a public endpoint, but it's something.

[Joe Sapinoso]

Hi @Daniel Eads , is there yet a timeline for us being able to retrieve this information from a public endpoint yet? It is becoming increasingly difficult to manage our users as our organization grows, so having this available would really help us out. 

Thank you.