Discover M-Files Workspaces: All work available in the right business context, automatically!
➡️ Learn How it Works

Options
  • State Suggested Answer
  • Replies 2 replies
  • Answers 2 answers
  • Subscribers 12 subscribers
  • Views 190 views
  • Users 0 members are here
Related

Rest API Authentication

Jannik Hanser

Hello everyone,

I received a request from our client regarding authentication options. Unfortunately, I'm not very familiar with this topic. Perhaps someone has some experience with this or has a recommendation?

Thanks in advance.

Here's the client's request:

Specifically, we want to connect our in-house developed systems (Java backends, OAuth via Keycloak Cloud-IAM) to our locally hosted M-Files. We want to use the existing OAuth context for each system, not technical users. Typically, mechanisms like a token exchange are used to convert the respective backend token into an M-Files token. We can't retrieve a token via the REST API because we don't know the password within the application itself (so POST /REST/server/authenticationtokens is not an option).

The option we looked at (Federated Authentication in the Vault configuration) is, in my opinion, not relevant for using the REST API.

  • 0

    I assume that you already have M-Files configured to do authentication against whatever IDP you are using.  That obviously has to be the first step.  Once users can authenticate using that IDP to M-Files then it becomes a matter of ensuring that you get a valid token to use the REST API.

    When it comes to OAuth tokens, the REST API simply passes them across to the server which checks their validity.  If the IDP you are using supports token exchange, and you can exchange the user's current OAuth token ("token 1") for one which is valid for the M-Files client configuration ("token 2"), then providing that new token ("token 2") to the REST API via the authentication header (bearer token) should work.

    I haven't personally done this, but as long as the token you have is valid then the REST API should accept it.  The question then becomes how to exchange token 1 for token 2, but that's more to do with your IDP and OAuth provider than M-Files.

    I don't have a huge amount more I can say here (as I said: I have not personally done it), but provided you can exchange token 1 for a token that is valid according to the M-Files authentication configuration (token 2) then I can't see why M-Files would reject it.

  • 0

    For a little more clarity, I think maybe this page explains it well: Set up OAuth 2.0 On-Behalf-Of Token Exchange | Okta Developer.

    In the diagram on the page you see that "App 1" (your application) communicates with the IDP (Okta, in the case of the diagram) to obtain a token for "App 2" (M-Files).  Once it has the token, App 1 can then communicate directly with App 2 in context of the user.  There's basically nothing done at the "App 2" (M-Files) side; provided the token is valid then it should just work.

    The page details how you'd get token 1 from the IDP (in "Authorization Code with PKCE request", as I assume your app is currently doing), then details how you'd get token 2 via a token exchange request ("Token exchange request from service app to API").  The key here is ensuring that the token you get is valid according to however your authentication is configured in M-Files; for that you'd need to work with the local IT team to understand how it should work.

    I doubt that the trusted-servers section is relevant (as I assume you'd be using the same authorization server), but I guess it could be depending upon your local context.

M-Files
M-Files Support


© 2025 M-Files, All Rights Reserved.