Accessing an endpoint from two different systems

[hamdyl]

Dear Developers,

We have an existing System A (UI and backend) that utilizes OKTA for access control. When a user requests data, e.g. searching, the access token and the API key plus some other details are passed to a backend API. System A has its own OKTA client ID & secret, authorization server, and API key.

Now we are implementing a new System B that calls some of the System A APIs directly, e.g. https://system-A-domain-url/api/getFilteredStores. This will be REST calls. Is it possible to design the OKTA access permission for System B so it can obtain an OKTA access token (through a REST call using System B client ID and secret, authorization server) and pass the token, its API key plus other required details to the System A getFilteredStores endpoint to retrieve some info?

Basically we don’t want System A and B share same credential client ID, secret, API key, and authorization server (if it’s possible). Is this type of setup possible? If not, do you have a better idea? We cannot change whatever we have implemented in System A.

Thanks.

PS:
System A was designed as end-user - backend interaction. A user is authenticated through OKTA login, the access token is stored and passed to backend API. It is deployed with AWS CloudFront.

[phi1ipp]

Well, usually if you want to talk to A, you need an authZ server of A to grant you an access token, right?

I’m not sure, what B does, but for the calls to A it will have to go to authZ server of A for the token. Of course it can be a completely different client_id/client_secret (probably an app with client_credential flow, if you are acting from the app B itself, and not on behalf of the user signed into B).

But what is your concern regarding sharing the same authZ server between those 2 apps? You still can create access policies in Okta for each of the applications, so …

[hamdyl]

Thanks phi1ipp.

Our concern is to provide restriction (maybe in the future) which endpoints are allowed and may audit trail. Anyway, we resolved the problem. It was coding issue for checking a client ID - we need to check for any allowed client ID.