The answer depends on a couple of factors, but the below should clarify the case where the end users permissions should be used.
There are 2 big sides of the story:
- What SDK to use (or alternatives)
- What authentication to use (or alternatives)
Ontology SDK aspects
OSDK clients are typically scoped to a single ontology via the developer console application registration and the Oauth2 client.
Since OSDK 2.0, you can define which ontology to connect to in the createClient method:
const client = createClient(foundryUrl, ontologyRid, auth);
You can pass in a different ontology RID at runtime than when creating the client, as long as the API names of the entities are the same across ontologies, the same generated OSDK code will work against the other ontology.
Authentication aspects
The authentication is the main challenge, as each developer console application is scoped to a single ontology.
If you use end-user tokens (authorization code grant), the token permissions is always the intersection of the user’s permissions and the developer console application scope. So if you want to use the user’s permission, the token is restricted to the ontology, and the resources, defined in the developer console application.
If you use service users (client credentials grant), the token is also the intersection of the service users permissions and the developer console application scope. The service user needs to have access to those resources AND those resources should be added to the developer console application.
One alternative is to create an “unrestricted” OAuth client, not tied to a given ontology or set of resources, by creating a third party application in control panel. This will circumvent the developer console’s resources intersection. This is generally not recommended, as this creates a fairly large scope of access for the token.
Recap of approaches
Option 1 - One OSDK client per Ontology + swap at runtime
Given you can instantiate an OSDK client at runtime towards a specific ontology, you can choose which ontology you connect to at runtime.
The main downside is the “alignment” of the SDK with the different ontologies. This is similar to juggling with different backends: if the ontologies diverges, you might face API calls failures (e.g. because a property is missing, etc.)
If you need to access multiple ontologies at the same time, then you must instantiate a separate client for each ontology access. Like:
const clientA = createClient(foundryUrl, ontologyRidA, auth);
const clientB = createClient(foundryUrl, ontologyRidB, auth);
Option 2 - Multiple Dev console Apps + swap client IDs
You could create multiple developer console applications, each one connecting to a different ontology. You could then use the SDK of one, or all; and use the authentication mecanism of each one so that you get the right intersection of permissions.
Option 3 - Unrestricted OAuth2 client
You can create one SDK on one of the ontology (that matches the schema of all) and use an unrestricted client for the auth part.
Option 4 - Custom API client (not OSDK)
In Developer Console, you can select the documentation as “simple curls” in the top right dropdown, which gives you the raw API calls for each endpoint exposed. From there, you can construct your “own OSDK” with the endpoints exposed, and you can handle the permissioning via an unrestricted OAuth2 client.
Option 5 - Consolidate Ontologies
Lastly, you could consolidate and review the structure of the use-case by having a single ontology to connect to, which you remove the need in the first place.