Possible to get RDM REST API access in user context?

Hello,

I have moved your post to the Devolutions Server API and SDKs section.

I'll ask our developer team if there is a way to get access using the user context instead of the application identity and get back to you.

Best regards,

Hello,

Thank you for your request. Could you elaborate on your use case and your needs? Unfortunately, we don't have an easy way documented today to get a token for a specific user. However, it is possible to use our PowerShell module (available here) and open a session in your user context. Is it a solution that could be used for your use case? Our PowerShell module allows you to request vaults, entries, and passwords in a similar way that you can do it with our public API.

If PowerShell is not an option, we could see if we could document the authentication flow with OAuth (device flow). The downside of that solution would be the token refresh. I'm not sure you would like to script calls to another endpoint to refresh the token every few minutes. So, I'm not sure it would be a viable solution. Don't hesitate to give me your input on that.

Another solution would be to add a new feature where an "application password"/"application key" could be created for a user and used to log you in DVLS, but we don't have that development plan short term.

Give me more hint on your needs and we will try to help you with pleasure.

Best regards,

This would be a great addition to the REST-API!

Hello,

Thank you for your request. Could you elaborate on your use case and your needs? Unfortunately, we don't have an easy way documented today to get a token for a specific user. However, it is possible to use our PowerShell module (available here) and open a session in your user context. Is it a solution that could be used for your use case? Our PowerShell module allows you to request vaults, entries, and passwords in a similar way that you can do it with our public API.

If PowerShell is not an option, we could see if we could document the authentication flow with OAuth (device flow). The downside of that solution would be the token refresh. I'm not sure you would like to script calls to another endpoint to refresh the token every few minutes. So, I'm not sure it would be a viable solution. Don't hesitate to give me your input on that.

Another solution would be to add a new feature where an "application password"/"application key" could be created for a user and used to log you in DVLS, but we don't have that development plan short term.

Give me more hint on your needs and we will try to help you with pleasure.

Best regards,

Hello,

We want to use Kerberos and SSO for API-Authenticaiton.
Why:

1. Usage for API for none PowerShell-Scripts for example Python, C# and so on.
2. No API-Keys need to be saved in cleartext in any scripts or applications.

With the current solution there is always the need to safe the api-key in (in none PowerShell-Scripts) cleartext and we would have to use another product just to store api-keys.
With the addition of kerberos-auth no additional tool would be needed

An advantage of this solution would be that powershell could rely on the API and not the RDM without an UI.

Best regards!

Hello,

Our server supports the device code authentication flow. You can refer to this article for information;
https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow

I've roughly documented the steps to do so. I also provided you with a sample to obtain an access token using a device code flow written using Powershell.

1. Discover Endpoints:
Query the well-known OpenID configuration endpoint to retrieve the server’s endpoints, specifically the token endpoint and the device authorization endpoint.

2. Request a Device Code:
Send a request (client ID: "dvls", scopes: "openid offline_access") to the device authorization endpoint. In response, you receive a device code, a user code, a verification URL (and a complete verification URL), plus details about how long the code is valid and how frequently to check.

3. Prompt the User:
Direct the user to the provided verification URL (or automatically open their browser) so they can enter the user code and approve the device’s access request.

4. Poll for the Access Token:
Start a loop that periodically sends a request to the token endpoint with the device code and client ID. Continue polling until the server confirms that the user has authorized the request by returning an access token.

5. Refresh the Access Token:
When needed, use the refresh token (obtained alongside the access token) to request a new access token from the token endpoint, ensuring ongoing access to the application.

Best regards,

Hi,

Device Based Auth is not feasible for our usecase. Imagine several central systems, all with different users and rights. Every system manages several workflows with the need to access passwords. The easiest solution (for us) would be, to leverage Kerberos SSO via the API, as the scripts are run in the user context, but not necessarily with powershell.
The current solution only works with powershell - and only with your ps module since it leverages dll files from the RDM client. If anyone does not wnat to use ps, but leverage the KRB Auth with any other means, there is currently no way to do so.
If possible, the SSO feature from the Web UI would be nice to have in the API - without ps module.

Hello,

Thank you for reaching out to us. We want to make sure we fully understand your use case and requirements, but based on your message, it's not entirely clear what your exact needs are. If you've already explored our official PowerShell module (Devolutions.PowerShell) or logging into the API using a standard application user/password and found that these approaches don't meet your needs, the next option would be to manually obtain an OAuth token and include it in the authorization header of your requests.

When it comes to scripting scenarios, we recommend the device code flow, as it is simpler to implement for non-interactive contexts. We also support the authorization code flow with PKCE, but it tends to be more complex and is generally not intended for automation.

The PowerShell script we provided is only meant as a reference to illustrate the necessary HTTP calls. It doesn't rely on any DLLs from Remote Desktop Manager—it's purely a set of examples showing how to request and refresh access tokens. You can adapt this logic to any programming language or environment you prefer.

We understand that an API key feature (with user-specific permissions) could simplify your workflow. However, as François mentioned, this functionality isn't in our short-term roadmap.

If there's anything else we can do to assist you or clarify, please let us know.

Best regards,