Skip to main content
Solved

Regarding users managed by the Control Room API, how to maintain multiple authentication tokens


Forum|alt.badge.img+3

I am using the Control Room API from an external system with a single API user. A Token is issued every time an API process is executed. When a second system issues a Token while the first system is repeatedly processing APIs with the Token, the API process in the first system encounters a 401 authentication error.

I understand that this is a situation that occurs because the first Token becomes invalid at the moment the second Token is issued.
 

I have two questions that I’d like to confirm with experienced or knowledgeable individuals.

  1. Is it possible to configure the tokens to remain valid within the expiration time, even if they are issued multiple times?
  2. To achieve this configuration, is it sufficient to enable multi-login for users as mentioned on the page below, and to specify the option “multipleLogin”: true when calling the authentication API?


https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/administration/users/cloud-multi-login-user.html
 

Best answer by Matt.Stewart

Hey ​@Ryutata , the Multi-Login doesn’t prevent your token from being overwritten by multiple executions.  It allows you to have a UI and API connection simultaneously.  This is primarily used so that a human can be logged in working while having bots do something, otherwise you get kicked off each time your bot authenticates!

There are a few solutions for you though:

  1. Follow this guide with your control room admins:

https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/administration/roles/cloud-control-room-apikey-role.html

API Keys can be used across multiple interactions simultaneously.  There is some maintenance associated though since they expire after a few months by default.  If your control control room admins allow you to generate keys that never expire, you could do this and forget about it forever.

  1. Externalize your token variable:

This is more difficult architecturally, but also requires no maintenance while setting up and no dependency on anyone else to do anything for you. The Bot needs do the following in this order: 1) Gather the token from the credential vault. 2) Attempt to do a transaction. 3) If it fails, get a new token. 4) Put it back in the credential vault via API 5) Use the token to do the transaction.

This means that all the instances of the bot are attempting to use the same token and will never invalidate the other’s use.  And whichever bot execution happens to attempt to use it when it first becomes invalid will repair it for all other executions.

 

 

View original
Did this topic help answer your question?

4 replies

Aaron.Gleason
Automation Anywhere Team
Forum|alt.badge.img+10
  • Automation Anywhere Team
  • 503 replies
  • January 30, 2025

No there is not. Just hit the authentication API each time. Don't make it more complicated than it is. 😅


Forum|alt.badge.img+3
  • Author
  • Cadet | Tier 2
  • 8 replies
  • January 31, 2025

I think my explanation was confusing. 
So I have organized my situation below

 

--action of the external system----
1.Create AA token
2.Create a work item in a queue
<Loop(Execute every 3 minutes until the status become "failed" or "completed")>
    3. Get AA workItem status
---------------------------------  

 

When this external system is executed twice almost at the same time, 
as shown below, "Execution1"  fails  because the token is invalidated.

 

[Execution1] 1.Create AA token > Done 
[Execution1] 2.Create a work item in a queue
[Execution1] 3. Get AA workItem status > Done (status = "running")
[Execution1] 3. Get AA workItem status > Done (status = "running")
[Execution2] 1.Create AA token > Done 
[Execution2] 2.Create a work item in a queue
[Execution2] 3. Get AA workItem status > Done (status = "running")
[Execution"1"] 3. Get AA workItem status > Failed 401 error (Token was invalideted )

 

Based on the above premise, could you tell me whether this solution works well or not?

 

[solution]
- Enable multi-login for the API user in the Control Room settings
- Add parameter { “multipleLogin”: true} when isuue the token.


Matt.Stewart
Automation Anywhere Team
Forum|alt.badge.img+6
  • Automation Anywhere Team
  • 10 replies
  • Answer
  • January 31, 2025

Hey ​@Ryutata , the Multi-Login doesn’t prevent your token from being overwritten by multiple executions.  It allows you to have a UI and API connection simultaneously.  This is primarily used so that a human can be logged in working while having bots do something, otherwise you get kicked off each time your bot authenticates!

There are a few solutions for you though:

  1. Follow this guide with your control room admins:

https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/administration/roles/cloud-control-room-apikey-role.html

API Keys can be used across multiple interactions simultaneously.  There is some maintenance associated though since they expire after a few months by default.  If your control control room admins allow you to generate keys that never expire, you could do this and forget about it forever.

  1. Externalize your token variable:

This is more difficult architecturally, but also requires no maintenance while setting up and no dependency on anyone else to do anything for you. The Bot needs do the following in this order: 1) Gather the token from the credential vault. 2) Attempt to do a transaction. 3) If it fails, get a new token. 4) Put it back in the credential vault via API 5) Use the token to do the transaction.

This means that all the instances of the bot are attempting to use the same token and will never invalidate the other’s use.  And whichever bot execution happens to attempt to use it when it first becomes invalid will repair it for all other executions.

 

 


Forum|alt.badge.img+3
  • Author
  • Cadet | Tier 2
  • 8 replies
  • February 3, 2025

Hello,Matt.Stewart -san
Thank you for your response. I understand that the multi-login setup cannot solve the token overwriting issue.

Thank you very much for your proposal of solutions. We will continue to consider our response based on the information you have provided.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings