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.

Parents
  • 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.

Reply
  • 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.

Children
No Data
M-Files
M-Files Support


© 2025 M-Files, All Rights Reserved.