I’m attempting to use the Okta API to retrieve an access token via postman. Currently, I have everything working with calling the /authn endpoint first to get the sessionToken, then calling the /authorize endpoint to get back the access token. However, in doing this, I’ve found that I need to setup Postman to include the clientSecret of the app I’m calling against which I need to avoid doing to allow our QE team to replicate this via automation scripts.
Is there a way to retrieve an accesstoken without using the client secret?
As a follow up note, I also would like to make it so the response from Okta returns a simple json object as today I’m having it return using the response_mode: form_post and parsing the html to get the hidden input value for accessToken. I would like to make that easier by just parsing a json response, but from what I have found I can’t see anything that does that currently.
If you are using an application with a Client Secret (Web or Native app types), then you will always need to include the client secret for endpoints that require client authentication.
What API are you doing that requires client authentication? Neither the /authn nor /authorize endpoint require this, so I’m not sure what endpoint you’re using.
The only way to get a token without needing a client secret for this type of app is to use implicit flow, which is less secure that authorization code flow and no longer recommended for production applications.
The way our setup works, we have a client that is responsible for getting the access token and then calling the api with the access token that Okta provides. However, we don’t have a way to get the access token currently without providing the client secret. The flow I am attempting to use is for an automated testing solution to allow tests to run that automatically authenticate the user and get the access token back by calling the Okta APIs directly, and once it has that, it calls our APIs to perform the action that is being executed. I’m trying to eliminate the client application from the equation to be able to run the tests quickly. We can pass in a client secret to the call itself but for our QE team, they shouldn’t have the client secret to be able to call Okta directly.
I just don’t see a way to handle this without giving this team the client credentials. They will not be able to get tokens without the correct credentials for the client they are using.
Have you considered not going end-to-end testing and instead assert that the QE team is given a token that is either valid or invalid so they can test that the application functions correctly in both situations without actually requesting actual tokens?
I do have the clientId that is provided, I was hoping to bypass needing the clientSecret specifically. I’m not actually attempting to do end-to-end testing in this app, but for each API call I am making, we need an access token that is provided by Okta to be able to make the call, and I was hoping to get that access token with a user name and password and the client id of the application.
I was able to get this to work. I called the authn endpoint first, then I called the authorize endpoint second with the response_mode = form_post, as well as setting the response_type to be token. This returned an HTML form object which then I used Cheerio within postman to get the access_token hidden input form value and set that. I did not need the client secret to be able to make this call to get the access token.