Ok, I’m hitting a roadblock, and feel like I may have made a bad assumption somewhere. If anyone can tell me if I’ve gotten this wrong, then please let me know where and how. (Or if this should work, then that’s good to know as well.)
I’m trying to make an integration that helps automate Okta for me. (Imagine a slackbot that you can talk to in order to add people to Okta groups, so they can get access to apps.)
Is this just something that shouldn’t work?
Is distributing apps to OIN that use the Okta API not a thing?
Does my buddy need to manually add my app into their instance somehow?
Do I need to add some extra args to the authorize call when it’s not my original dev instance of Okta?
I’m assuming the 400 error is happening because your buddy’s dev instance does not recognize the client_id and redirect_uri because those parameters are specific to your dev instance and not theirs.
Your application needs to be able store your buddy’s Okta org url, client id (and secret if you’re using a web app). Your application will also need to handle making /authorize and /token requests to different configurations.
When your app is published to the OIN, any Okta customer will be able to add your application to their org. Okta will then generate a unique client id (and secret) for them. They need to provide that to your application and you will store them. I’m not sure how you want to associate the user with the right org config. I’ve seen some applications ask for the org url and some applications that grant each customer their own unique domain (login.cust1.com).
I did read over the two docs you mention, but they never helped with my understanding. And I think that has to do with my expectations of how OAuth was implemented in Okta being similar to how Google/Microsoft/Slack/etc handled it. In those environments you have a single client_id with, for example, different rights to each Slack instance based on the scopes that you requested when the oauth code flow was done.
What it sounds like here is that the scopes part of oauth isn’t implemented in Okta, at least not like other integrations, and instead you get a unique client_id, and client_secret, which need to be manually configured in the target integration, per-tenant. So the admin of the target okta instance needs to configure those two items, instead of those being handled by the oauth flow.
At which point, if I’m doing server-to-server stuff (like I am) I might as well not use OIDC, since there’s no admin who can approve the scopes I need, since I can’t ask for them. And instead I tell the admins, in an install guide or the like(?) that I need scopes X and Y to work, and then use the Client Credentials flow instead.
Am I now understanding how to do this?
And if so, do I still submit this to OIN as a SSO integration, even though I don’t expect end users to ever sign into our app?
Right, Google and Slack function as Social Authentication providers that allow users that have an account in Google to access other applications by authenticating them through OAuth.
This is different from how Okta functions, which is more akin to a Federated model, like Azure AD, where the username is only unique within a specific Okta Org and the user must be sent to their tenant in order to authenticate.
Based on what you’re describing, I don’t see a benefit to submitting this as an OIN integration (we expect there to be a user scope with the submission and only accept Web and SPA integrations for OIDC apps) and think you’ll be fine just providing the admins for each org an integration guide to help them set it all up.