We are planning to implement API Services integration with our external members using Client Credentials Flow. As we have a several members access the same service(s), we wanted to make sure our approach is as per OKTA standards.
Here are the high-level points for the approach
- Create a new API Services integration for each external member so that they get their unique client id and secret to retrieve the access token. We also using OKTA API (PUT /api/v1/apps/{{appId}} ) to set the custom application property (app.profile.member.id) to uniquely identify each member with our internal identifier. We referred the following to setup custom application profile attributes.
-
Create a single Scope (example, member.inbound.execute) on default Authorization server. We have selected “Required” for User Consent and unchecked the “Block services from requesting this scope”
-
Create a single Claim (example, member.id) and apply this claim only for the above created scope (member.inbound.execute). Also populating the value of the claim using application custom property (app.profile.member.id) using Expression type.
So, when the member request for access token using their client id, secret and the scope, it includes the custom claim with their own identity as a value in the generated access token.
We validate the access token locally (also checks for Issuer and Expiration) and then using that custom claim value to differentiate each member. We also have some internal validation for the request before processing it.
So, could you please validate the approach we are planning to use and let us know if you see any issues? Also, we are going to use this under our default Authorization server and not planning for any custom Authorization server.
Also let us know how it impacts the pricing of our plan if at all by using the token URL for access tokens generation. Mostly our external members will cache these tokens and reuse until they expire.