UPDATE

As far as we understand it there are two different ways to authenticate for IFS Applications 10:

• Native: This is used for native applications like the IEE. Since the client runs on the local user machine, in theory a client secret could be acquired by anybody. Therefore only the client id (native) is needed.
• Web:    This is used for WebAPIs. The client secret is hidden by the backend server and cannot be acquired by anybody. Therefore the client id (web) and the client secret (web) is needed.

The same two ways of authentication are available for ADFS servers. This is controlled by the "resource" parameter.

• Native: api://PTY10
• Web:    ifs-pty01.me-group.local:51080

We now have a test case where we request a native access token from the internal IFS OAuth server.
As expected this access token does not work for the WebAPI. If we do the same test case with a web access token from the internal IFS OAuth server we are able to use the WebAPI.
So far everything as expected. For the ADFS server we would expect it to work the same way.

---------------------------------------------------------------------------

In the meantime we managed to get a valid access token for the WebAPIs via ADFS with the resource parameter set to “api://PTY10” by simply leaving the value for the parameter “client_secret” empty.

Unfortunately, as described above, in my opinion it shouldn`t work with the parameter “resource” set to “api://PTY10” as this is the resource value for the “native” applications like IEE.

It seems like that there is something mixed up. Instead of getting a valid access token via "api://PTY10", we should have to use "ifs-pty01.me-group.local:51080". Can somebody tell us if our intention is correct, and where we have to change something?

In my opinion the ADFS server configuration is correct according to this documentation: https://docs.ifs.com/techdocs/foundation1/040_administration/210_security/015_authentication/030_configure_ADFS/default.htm

So the misconfiguration is probably somewhere in the IFS Middleware Server.

We would appreciate any help on this topic.
Thanks in advance.

CORRECTION OF MY LAST ANSWER

After I figured out a lot more about OAuth2 and I think I am understanding now how the Client Credential Flow and the Resource Owner Password Flow are working.

 As I mentioned in my last answer there are two different ways to authenticate:

• "native"/"public": Without Client-Secret
• "web"/"confidential": With Client-Secret

The reason why these two ways exists is explained here: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce

And to correct my last answer:
It doesn`t matter if you use the public login or the confidential login. Both are working for the WebAPI.

SOLUTION

The point where I was getting confused by the documentation was at the following line:

Give an Identifier. For documentation purposes giving the application server URL as the identifier is a good idea.

If the identifier of this WebAPI is freely configurable, the IFS middleware server cannot know it and thereby cannot set it as the resource parameter in its requests. So I deleted this WebAPI and as expected nothing happend because this WebAPI wasn’t even used.

A few lines later the documentation says that we have to create another WebAPI. But now, the identifier must follow the following pattern: api://<INSTANCE_NAME>

So far so good. What I did now, is that I added the “Aurena-Application” to the “Client Permissions” of this WebAPI. So instead of having two WebAPIs, I only have one WebAPI which has configured both the Native- and Aurena-Application (both with the permitted scopes ‘openid’ and ‘user_impersonation’).

I did not change anything in the configuration of the “Native application” and the “Server application” (“Aurena-Application”). I have also not changed anything on the IFS middleware server.

So in my opinion the documentation is not fully correct.

POSTMAN CONFIGURATION FOR PUBLIC & CONFIDENTIAL (MS ADFS & IFS IDP)