I am looking for a solution that will allow my external service, integrated into Okta as an OIN App, to read data from my customers’ Okta organizations. My goal is to avoid creating new Client IDs and Client Secrets for each instance of the app when added to a customer’s Okta organization.
Ideally, the Client ID and Secret are only used between my external service and the Okta App Integration. When a customer adds my app to their organization, they should only need to authorize the app to access their data without needing to manually copy and paste credentials into my external service.
I came across the solution “Implement authorization by grant type,” which looked promising. However, I read that this uses an “API Service Integration” where Okta generates a unique set of credentials (Client ID and Secret) for each organization. The API Service Integration documentation says:
“Customers can use any API service integration listed in the OIN catalog with their Okta tenant org. Each customer Okta org has its own authorization server that supports the Client Credentials flow. When a customer authorizes your API service integration to access their org, Okta generates a unique set of credentials (client ID and client secret) for that org.”
Does this mean the “Implement authorization by grant type” solution still creates new credentials for each customer instance of the app? If so, is there a way to avoid this and use the credentials only between my Okta App Integration and my external service, allowing my app to access customer Okta organization data without generating new credentials?
Finally, I’d appreciate an explanation of what “machine-to-machine communication” means in this context, specifically in relation to the Client Credentials flow and the statement “no end-user.” How does this apply to my scenario where my external service is accessing customer Okta org data?
What you are asking needs a longer explanation and maybe you need some help with developing this service. But I don’t like to see unanswered questions that show up in Google searches so I’ll try to keep it short to address it.
Most third-party applications that end up with an OIN integration use SAML for authentication. SAML exists to divorce the application from having to manage identity itself, user names and passwords in a database. Plus, adding MFA or other stuff just would complicate that. When the user lands at the application it redirects the browser to the Okta tenant (aka Organization). If Okta has a session for the user, it sends an “assertion” back to the application with the identity information. If the user is not authenticated, they have to authenticate at the Okta organization before that identity information goes back. Okta can provision additional information to the application, most of the time using the SCIM standard. But these applications have no rights to talk to the Okta API.
The section about Open Authentication that you quoted is fundamentally the same thing; the application is asking Okta for information about the authenticated user. OAuth and OpenID Connect (a sister protocol for carrying the identity information) are used more by customer facing applications. This is because the primary use of OAuth is for API access management. Besides the ID token going to the application there is an access token, issued by the authorization server you mentioned. This has API access rights for the user in it, and is used with every call to the API to identify who the user is and what they are allowed to do. Okta controls what they are allowed to do, not the application. Because how could we trust that? Unless I misread what you are asking for, this is only authentication and it doesn’t fit your request.
A M2M application is confgured in the Okta tenant to get an access token on behalf of the application, not for a user. The application uses a secret (password) or PKI to prove itself. This allows an application to do its own work with an API. Okta can issue tokens for your APIs, these are the authorization servers you quoted. Or Okta has a hidden authorization server that will allow an application to request an access token that talks to the API for the Okta organization. It sounds like that is what you are looking for.
So the first description is authentication (outbound), the second part is private or Okta API access (inbound). The second part is only used for applications managed by the tenant owner. It would be an extreme security risk to allow a third-party application to make an inbound connection and use the Okta API for the tenant.
If you want to talk about this in greater depth and you don’t have access to professional services, you can find me on LinkedIn.
Hi Joel, thank you for your answer, it helped us to understand how Okta work in this regard. My friend messaged you on Linkedin, can we ask you there one more question about Okta auth? Thank you!
