Skip to Main Content
Feature Request FR-4841
Product Area AI Features
Status CLOSED

2 Voters

Enable Additional Features for Generative AI Services

jonathan.wintermeyer Public · Mar 23 2026

Idea Summary
A current requirement of ours is to use an Azure AI Services OpenAI GPT-4 endpoint. However, an additional requirement is to use Azure AI Services API Management (APIM) in front of the endpoint. This requires OAuth2 authentication before sending the request with some additional headers: the API key, the user, and the application name. This is only possible currently by using a reverse-proxy because OAuth2 APEX Credentials are not able to be used with APEX Generative AI Services. Also, because the API key has to be hardcoded in the HTTP Headers field and there is no ability to use Substitution Strings for the user and the application name at the Workspace level in APEX. One of the big problems that we are running into is that when we use the AI for development assistance, there is no way to capture the user. We can work around this when the request is generated from an AI widget in an application by passing the user in the system prompt and replacing it in the headers, but there is no such option when the request is generated for development assistance.

Use Case
When using an Azure AI Services endpoint for an APEX Generative AI Service.

Preferred Solution (Optional)
Allow OAuth2 APEX Credentials to be used by APEX Generative AI Services and create a new substitution string (or something similar) feature for the Workspace level.

This request is likely a duplicate of FR-4846.

Comments

Comments

  • carsten.czarski APEX Team OP 3 days ago

    Regarding the OAuth authentication part, we'll mark this as a duplicate of FR-4846. 

    Regarding the ability to send additional HTTP Headers (besides the Authorization Header), does the existing HTTP Headers field within the Generative AI configurarion not suffice?

  • jonathan.wintermeyer OP 3 days ago

    @carsten.czarski  No. The big sticking point for the way the Additional HTTP Headers within the Generative AI Service configuration works is the requirement to capture the user, but hard-coding the app name and the API key in the additional headers isn't optimal either.

  • jonathan.wintermeyer OP 3 days ago

    Also, I'd say FR-4846 was a duplicate of this one. 03/23/2026 versus 03/26/2026.

  • carsten.czarski APEX Team OP 3 days ago

    Hi Jonathan,

    So … I would like to understand that authentication type better. Can you add “pseudo” curl requests to indicate how the LLM has to be called in your case? Is there a standard OAuth2 flow? Is there some special flavor?

  • eric.olson OP 3 days ago

    For us, the OAuth2 flow is the standard client credentials flow, so after requesting an authorization token, the request to the AI would look like this. The last three headers are the ones being required by our enterprise's Azure API Management layer. UserPrincipal is especially annoying because it's supposed to be the identity of the logged-in user and isn't static.

    curl -X POST -d "@./ai-query.json" \
    -H "Authentication: Bearer <token>" \
    -H "Content-Type: application/json" \
    -H "api-key: <hex string>" \
    -H "UserPrincipal: john.smith@example.com" \
    -H "appName: oracle-apex" \
    "http://my-endpoint.example.com/gpt-4o/chat/completions?api-version=2025-01-01-preview"
  • jonathan.wintermeyer OP 3 days ago

    @carsten.czarski This is an example of how we would make the AI call with curl.

  • carsten.czarski APEX Team OP 2 days ago

    Hi everybody,

    with roadmapped idea FR-4648 we will look into extending Generative AI services to also support the other authentication types, which APEX provides for REST Data Sources, i.e. OAuth variants, URL query string, HTTP header, Basic and so on.

    Similar to REST Data Sources, it will become more difficult, there more special and non-standard an authentication flow gets. For instance, the above example does not really follow the OAuth standard, which only requires the access token to be sent with the actual REST Request. Sending additional information like API Keys or user name (which is non-standard), with non-standard HTTP headers will make a generic low-code implementation hard - as Web Credentials are supposed to keep the stored credentials secret.

    We will look into this enhancement and see what we can do. It's very likely that support will arrive in phases …