Hi, I have a use case that needs to authenticate other applications to directly access to my APIs. Is there a way to authenticate users without going to a front end (either a okta hosted front end or custom login front end). I’m using the authorization code flow to authenticate users but need to find a way to authenticate other applications. Is API access management the right way to go or the v1/authn api call? Thank you!
From what you are describing, it sounds like you want to have a machine-to-machine interaction, where service applications request tokens that they can use to access your APIs.
Do you need the tokens issued for these other applications to have information about a specific user, or could each application instead have a unique client associated with in in Okta to grant them their own Client ID/Client Secret credentials?
Thanks for responding! I assume each application could have a client ID and client secret with Okta. But my question is even with that being each application is in the same “org” as my application, how would these applications access my application’s APIs?
If you’re protecting API endpoints, you could have these customers/users
- request an access token using Client Credentials flow
- send that Access Token as the authorization when making calls to your APIs
If you need a reference to what this can look like, you should check out our resource server samples:
Note that those samples are designed to play well with our SPA Samples, but it uses the logic I described above to accept the access token and then validate them locally
If this is simply an API, you may want to check out our blog examples which are more specific to that use case:
This could be a stupid question but from looking at some blogs like this one: Build and Secure an API in Python with FastAPI | Okta Developer Do other machines trying to access my API endpoint use their okta client ids and client secrets or do I need to share my client ids and secrets?
The Client ID and Secret will typically be created within your own Okta tenant, so that you can easily validate all the tokens sent to your endpoint against the current signing key for the authorization server you create for this API.
If you’re looking to have outside parties or various applications/clients interact with your API, you may want to give each application its own Client in your Okta instance (therefore, their own Client ID/Secret pair) so its easier to revoke access to a single client/machine if needed.
For example, if these other machines represent customers of yours, you would create a new client application for them and then share the newly created credentials with the individual service.
Your options likely depend more on your specific use case. Are these other machines external to your company/control? Are you implementing microservices?