I am in the process of developing a WinForms client application that consumes REST APIs in IFS Applications 10 using OAuth/OpenID. The customer is using Azure AD as the identity provider.
Due to the limited access to the Azure AD configuration I couldn’t test the same using Postman that requires redirect URL to be configured. The Password Credential flow using postman worked and returned the token. But API access was rejected with 401.
Additionally, after “Include in compatibility type”=enabled in the projection the basic auth call also returned 401.
Is there any additional configuration/permission that is needed for this to work?
The flow I am using is Authorization Code Flow and I managed to successfully obtain a token. The failure is resulted when I communicate with IFS APIs using the token. When investigated further on the error description (WWW-Authenticate header) it was bit unclear as the error messages mentions about id_token.
As stated in the documentation, when tried with access_token the following response is returned
Bearer realm=<client_id>@https://login.microsoftonline.com/<tenant_id>, scope="openid", authorization_uri=https://login.microsoftonline.com/<tenant_id>, error="invalid_token", error_description="573fb18d-3879-400e-88ff-9c8a64ef1135: Signature of the provided id token could not be validated against the public signing keys of the identity provider."
When I send a request with id_token, I am getting the following response (WWW-Authenticate header). Which says that the issuer is not a trusted party. Am I missing any configuration?
With further investigation I managed to find the cause of the problem. My client application uses MSAL (Microsoft Authentication Library) to authenticate and acquire token for the user from Azure AD. The library by default uses Azure AD 2.0 endpoints. The tokens returned from 2.0 endpoints are not compatible with IFS Applications 10. Which resulted in the above mentioned error responses.
Solution
The solution was to change the scopes parameter to be compatible with Azure AD 1.0 endpoint. The following documentation details about using MSAL with v1 scope usage.
With further investigation I managed to find the cause of the problem. My client application uses MSAL (Microsoft Authentication Library) to authenticate and acquire token for the user from Azure AD. The library by default uses Azure AD 2.0 endpoints. The tokens returned from 2.0 endpoints are not compatible with IFS Applications 10. Which resulted in the above mentioned error responses.
Solution
The solution was to change the scopes parameter to be compatible with Azure AD 1.0 endpoint. The following documentation details about using MSAL with v1 scope usage.
Based on this, the scope value “{client_id}/{oauth2Permissions_value}” is used (instead of “openid”).
oauth2Permissions_value: this must be obtained from the Azure AD application manifest reference. In my case the value is “user_impersonation”.
Application Manifest Reference
Thanks everyone
Hi @avenash
i have same issue & still not resolved.
i’m getting token by using oauth2 successfully, & using that token but got 401 unauthorization while request some IFS API.
can you share to me how you get the token & how to use that token to request IFS API ?
thank you.
I am in the process of developing a WinForms client application that consumes REST APIs in IFS Applications 10 using OAuth/OpenID. The customer is using Azure AD as the identity provider.
Due to the limited access to the Azure AD configuration I couldn’t test the same using Postman that requires redirect URL to be configured. The Password Credential flow using postman worked and returned the token. But API access was rejected with 401.
Additionally, after “Include in compatibility type”=enabled in the projection the basic auth call also returned 401.
Is there any additional configuration/permission that is needed for this to work?
The flow I am using is Authorization Code Flow and I managed to successfully obtain a token. The failure is resulted when I communicate with IFS APIs using the token. When investigated further on the error description (WWW-Authenticate header) it was bit unclear as the error messages mentions about id_token.
As stated in the documentation, when tried with access_token the following response is returned
Bearer realm=<client_id>@https://login.microsoftonline.com/<tenant_id>, scope="openid", authorization_uri=https://login.microsoftonline.com/<tenant_id>, error="invalid_token", error_description="573fb18d-3879-400e-88ff-9c8a64ef1135: Signature of the provided id token could not be validated against the public signing keys of the identity provider."
When I send a request with id_token, I am getting the following response (WWW-Authenticate header). Which says that the issuer is not a trusted party. Am I missing any configuration?
I am not sure if I am missing anything related to configuration.
With further investigation I managed to find the cause of the problem. My client application uses MSAL (Microsoft Authentication Library) to authenticate and acquire token for the user from Azure AD. The library by default uses Azure AD 2.0 endpoints. The tokens returned from 2.0 endpoints are not compatible with IFS Applications 10. Which resulted in the above mentioned error responses.
Solution
The solution was to change the scopes parameter to be compatible with Azure AD 1.0 endpoint. The following documentation details about using MSAL with v1 scope usage.
Based on this, the scope value “{client_id}/{oauth2Permissions_value}” is used (instead of “openid”).
oauth2Permissions_value: this must be obtained from the Azure AD application manifest reference. In my case the value is “user_impersonation”.
Application Manifest Reference
Thanks everyone
avenashwrote:
With further investigation I managed to find the cause of the problem. My client application uses MSAL (Microsoft Authentication Library) to authenticate and acquire token for the user from Azure AD. The library by default uses Azure AD 2.0 endpoints. The tokens returned from 2.0 endpoints are not compatible with IFS Applications 10. Which resulted in the above mentioned error responses.
Solution
The solution was to change the scopes parameter to be compatible with Azure AD 1.0 endpoint. The following documentation details about using MSAL with v1 scope usage.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.