Pre-authenticated requests provide a way to let users access a bucket or an object without having their own credentials, as long as the request creator has permissions to access those objects. For example, you can create a request that lets an operations support user upload backups to a bucket without owning API keys. Or, you can create a request that lets a business partner update shared data in a bucket without owning API keys.
When you create a pre-authenticated request, a unique URL is generated. Anyone you provide this URL to can access the Object Storage resources identified in the pre-authenticated request, using standard HTTP tools like curl and wget.
Understand the following scope and constraints regarding pre-authenticated requests:
Users can't list bucket contents.
You can create an unlimited number of pre-authenticated requests.
There is no time limit to the expiration date that you can set.
You can't edit a pre-authenticated request. If you want to change user access options in response to changing requirements, you must create a new pre-authenticated request.
The target and actions for a pre-authenticated request are based on the creator's permissions. The request is not, however, bound to the creator's account login credentials. If the creator's login credentials change, a pre-authenticated request is not affected.
You cannot delete a bucket that has a pre-authenticated request associated with that bucket or with an object in that bucket.
Understand the following scope and constraints regarding public access:
Changing the type of access is bi-directional. You can change a bucket's access from public to private or from private to public.
Changing the type of access doesn't affect existing pre-authenticated requests. Existing pre-authenticated requests still work.

If your organization is small, or if you are still in the proof-of-concept stage of evaluating Oracle Cloud Infrastructure, consider placing all of your resources in the root compartment (tenancy). This approach makes it easy for you to quickly view and manage all your resources. You can still write policies and create groups to restrict permissions on specific resources to only the users who need access. If you plan to maintain all your resources in the root compartment, we recommend setting up a separate sandbox compartment to give users a dedicated space to try out features. In the sandbox compartment, you can grant users permissions to create and manage resources, while maintaining stricter permissions on the resources in your tenancy (root) compartment. https://www.oracle.com/a/ocom/docs/best-practices-for-iam-on-oci.pdf