is client id / consumer key / apikey all the same?
Hi @edward! Welcome to our Okta Dev Forum. The short answer to your question: no, they are not the same. Client id is used in OAuth flows see for example - OAuth 2.0 and OpenID Connect overview | Okta Developer; it represents your app. Meanwhile API Key is used to authenticate/make requests to Okta backend resources - Create an API token | Okta Developer. Lastly, I’m not familiar with consumer key, what context is this under?
I’ve heard consumer key and apikey are interchangeable. In other systems like google’s Apigee, apikey is consumer key.
It is kind of confusing. In google’s Apigee, I create a devapp (aka app in Okta) and then Apigee will generate a consumerkey/secret. If I will do oauth on Apigee, I will need the consumerkey/secret to generate say access tokens/refresh tokens. I can call an API on google’s apigee gateway by passing my consumerkey (aka apikey).
But in Okta, are you saying, I create an app and Okta will generate a clientid/secret which I can use to do oauth so I can get access tokens/refresh tokens. And I have to create an API key so I can request okta backend services similar to me calling an API in google’s apigee gateway?
Hi there @edward !
Thanks for clarifying!
In Apigee, the consumer key sounds similar to what I call a static API token because it sounds like you use the same key value for your API calls. If you pass in your consumerkey/secret to generate an access token, then you are using OAuth Client Credentials. This method does not use a private key JWT which elevates the secure posture of utilizing tokens which is why we recommend it.
In Okta, when you create the machine-to-machine app, you can select to use public/private key instead of clientId/secret. You’ll use the public/private key to request an access token from Okta for subsequent Okta API calls.
LMK if you have more questions!
Correct, in Okta world, API key =/= OAuth tokens, which, as you said, involves generating a client id/secret and serves a different purpose. The first is a static token that authorizes to Okta resources, and the latter is shorter-lived and authorizes to your backend resources. As best practice we recommend using OAuth tokens - Why You Should Migrate to OAuth 2.0 From Static API Tokens | Okta Developer.