Replies: 2 comments
-
As background, the Management API is not designed to be exposed over a public network such as the internet. Authentication is, therefore, constrained to backend systems that operate as clients to that API. If you would like to use OAuth2 for such clients, this can be done by implementing Given that API keys are a perfectly valid authorization method for such scenarios (the OAuth2 Client Credential Flow is basically a form of API key with enhancements), they are much easier to deal with than OAuth2, and the latter can be easily added via an extension, we are not likely to provide OAuth2 out-of-the-box support for the Management API. |
Beta Was this translation helpful? Give feedback.
-
As discussed in EDC extended sync on Feb. 27th, the option to offer OAuth2 will be discussed for PI13. |
Beta Was this translation helpful? Give feedback.
-
Today, the X-API key is used as the authentication method for the EDC management API. We would prefer to use oauth2 as the authentication method for the following reasons.
OAuth2's use of short-lived access tokens enhances security by minimising the window of vulnerability in the event of token compromise. In addition, OAuth2 enables seamless integration with external identity providers (IDPs), streamlining the authentication process. Using OAuth2, applications can delegate authentication responsibilities to trusted IDPs, reducing the risk of credential exposure and enabling single sign-on (SSO) capabilities.
In the case of a managed EDC, the API key is under the control of the service provider.
Beta Was this translation helpful? Give feedback.
All reactions