This is my first OIN OAuth Integration, and I have a basic question I can’t find answered in the docs.
UNDERSTOOD - When onboarding SSO Users, I request the Client_ID, Client_Secret and Issuer from the SSO User to set them up on my application’s server.
ALSO IT’S POSSIBLE for an Okta org/Issuer, in order to give their users different configuration options for an app, have the ability to run multiple instances of the same app, therefore multiple Client_IDs/Client_Secrets are present for any given Issuer.
In order for me to compose the Authorization URL, I require the Client_ID and Client_Secret of the instance of the app that the requesting User clicked on, however, only the Issuer is sent in the initial request when the User clicks on the app from their Dashboard.
Any insight on how to pick the Client_ID and Client_Secret for the app that the user clicked on?
Hello! You can always make your Initiate Login URI in your app settings something like:
https://www.example.com?clientId={okta_client_id}
Just DO NOT send the client secret over like that. You would want to have an internal mapping in your backend server linking the right client IDs to their corresponding client secrets. Does that make sense?
Cale this makes perfect sense, and it will solve my problem.
I’m running into one problem. When I add this parameter to Initiate Login URI in the applications General tab, I get the following error message when saving:
The initiate login URI must be an absolute URI.
Is there another way I can customize the query string?
Hmm, it worked for me in a general OIDC app but there might different guidelines for an OIN submission. Can you attach a screenshot of your attempt to change the URI and the subsequent error message?
When the user is redirected to your app (via the initiate login URI), we’ll send over the ‘iss’ value automatically (which will be the Okta domain url), but there’s no real way to send over the client id.
As it stands right now, we don’t have a good way to support multiple instances of the same OIN OIDC Application in a single tenant, which I’m guessing is your use case.
