Hi Team,
I have a use case where i want grant_type both password and client_credentials but i don’t see any options under native app.
And when i trying to the hit the /token api with grant_type=client_credentials then i am getting below error:
{“error”:“unauthorized_client”,“error_description”:“The client is not authorized to use the provided grant type. Configured grant types: [authorization_code, refresh_token, password].”}
Please suggest…
Thanks,
Best Regards,
Manjit Kumar
Any suggestion or comment?
Thanks,
Best Regards,
Manjit Kumar
Hi @mksmanjit,
As a word of caution, using the grant types of either password
or client_credentials
are an anti-pattern for native apps. You’re going to be embedding a client secret into a publicly distributed application, so your application is no longer “private”.
If you’re wanting to use client_credentials
as the grant_type
, you’ll need to setup an Okta application as a Service as opposed to a Native App. You can read documentation on that here.
However, in order to build a secure application, I would strongly suggest you reevaluate using the password
and client_credentials
flows and favor the Authorization Code Flow with PKCE. It is also detailed as Best Current Practice via RFC 8252.
If that isn’t an option, can you help us understand your use case better?
Hi @jmelberg
Actually we have an application which is also an OAUTH2.0 application and we have exposed lot of APIs which our customer are going to use without any manual intervention.
Earlier we are doing authentication using our own /token API internally but now one of our customer is asking for SAML 2.0 support, and for that i did research and found that SAML 2.0 work well with only Web part.
So we want some way so that when our customer is using SAML 2.0 he should also able to authenticate(/token) and also use our APIs as well but as with SAML 2.0 all the authentication mechanism and credentials detail are moved to the IDP server.
So we planned to use OAUTH2.0/OIDC APIs to get authenticated on IDP server, and lot of our customer did automated cases where they already provided the credentials and they don’t want any manual intervention.
For that reason we came up to use grant_type=‘passoword’ and we decided that we will ask user to enter the OAUTH2.0/OIDC ‘/token API’,Client ID,Client Secret and scope on our application before using the APIs.
Here we need grant_type=‘client_credentials’ so that i can validate that details entered by user
is correct or not after connecting to it using RESTClient in the backend, if details are valid
then store them otherwise return error message.
how authentication will perform
User will hit our own /token API with username, password and grant_type=‘password’ and inside our /token APIs we will create a REST Client where we create a call to OAUTH2.0/OIDC /token API by taking information which we asked user on our application and username and password is given by user during /token call.
In that way we will create one request and hit the OAUTH2.0/OIDC /token API, if the response for that call is 200 OK we assume that user is valid and will do some processing in our application.
Thanks,
Best Regards,
Manjit Kumar
Hi @mksmanjit,
Thanks for the explanation of your use case!
Per the description above, it appears you have your own internal API service that users are authenticating against. Of course, this requires a username and password (grant_type=password
). Then, you’re delegating to service-to-service communication via OAuth 2.0 (acting outside of user context).
I think the problem is we attempting to use the same OAuth 2.0 client for two authorization grant types, while they should be treated independently.
For the requested grant_type
:
-
password
: A token will be minted on behalf of the user (containing user context)
-
client_credentials
: A token will be minted on behalf of the service (no user context)
Based on your authentication scheme above, is there a reason you cannot proxy the user’s credentials from your API service out to Okta using grant_type=password
?
Hi @jmelberg,
Actually when i asking user to enter details like token URL, client_id, client_secret and scope, i just wanted to validate whether the details provided by user is correct or not and at that time i don’t have password due to which it is not possible for me to use grant_type=‘password’, so thats the reason i wanted to use grant_type=‘client_credientials’ here just for doing validation that details are correct.
And when user call our /token api he will provide the username and password and i will use above details( token URL, client_id, client_secret and scope) and i can directly hit /token api with grant_type=‘password’
So in short my whole purpose of using grant_type=‘client_credentials’ is to just validate the entered details.
Thanks,
Manjit Kumar