An OAC instance provides a number of REST APIs for programatic access. For example, a script can list snapshots with this command:
GET https://oac1.analytics.oraclecloud.com/api/lcm/api/v1/snapshots
Authorization: Bearer {access_token}
So far, the authentication step always requires an IDCS user access token. This proposal would also add support for OCI signed requests allowing the OCI native representation of a user to seamlessly flow to OAC.
More and more OCI services want to integrate with OAC but this is difficult. A very common use-case is maintaining user context. Service A receives a request from a user and wants to execute an OAC operation in the same user context. In the OCI ecosystem, this is known as an OBO request. Service A obtains an OBO token for the user (on-behalf-of token) and executes the OAC request with this OBO token.
Unfortunately, this is not supported with current OAC. The OAC REST API cannot make sense of OCI signed requests (with or without OBO tokens). It only understand IDCS OAuth tokens. This problem raises the integration bar significantly for partner teams. They must onboard to special IDCS features and fully translate the OCI user representation into an IDCS access token equivalent. This is a sizeable effort.
The proposal is to enhance the OAC REST API to have dual support for IDCS OAuth tokens and OCI signed requests. It would be similar to what the IDCS team have done for their API. Incoming requests would be either routed to CloudGate authentication (OAuth token) or a new component for OCI authentication (OCI signed request). After that, the request would continue as usual, reaching bi-security to establish the subject and finally authorization for BI approle permissions.
