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?
1 Like
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!
1 Like
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.