
ChrisG (Customer) asked a question.
Hello, I'm using Okta to protect a RESTful API using OpenID. This works well for authenticated users. I need to take the next step of further protecting the API and restrict consuming applications.
I want to acheive a flow where the calling application must be validated as an approved consumer of the API regardless of a successful authentication of the user. I can then apply thresholds, CORS policy, etc.
I'm asking in this forum because I'm looking for a best-practices implementation within an Okta eco system (though I do not expect this to be an Okta solution). My first thought is to implement an application API key that is used in ADDITION TO the bearer token--another header. Since API keys have received a bad reputation, I want to ensure that there hasn't been a more standard way patterned to acheive this use case. For instance, 3rd party api modules, api documentation generators, etc-- all these have created solutions based upon assumed standards and I want to conform to those rigid or casual standards if possible.
Again, I basically want to approve the calling application in addition to OpenID. I would likely implement all the logic to do this in my API (versus any Okta work). Just looking for a link to or guidance on proper pattern.
