What is the purpose of a client secret?

Help
,
1

Hi, we want to let our customers programatically sign to our app using their username/password. I figured out the http://auth0.com/oauth/grant-type/password-realm grant type is way to go. In order to fetch the tokens, one has to send request such as this one:

curl --location --request POST 'https://tenant.auth0.com/oauth/token' \
--header 'content-type: application/json' \
--data-raw '{
    "grant_type": "http://auth0.com/oauth/grant-type/password-realm",
    "client_id": "client id",
    "client_secret": "secret",
    "username": "username",
    "password": "password",
    "realm": "Username-Password-Authentication",
    "scope": "openid email"
}'

Is it dangerous to share client_secret to our customers? What harm can they do to us with the client secret? The client secret is not used for signing the ID/access tokens, right? (we use RS256 encryption) If we create a new application for each customer, would it be safe enough? (so they don’t share the secret) Is there a better way to allow our customers programatically log in using their username/password?

2

hi @lukashavrlant

Welcome to Auth0 Community !!!

Even though Auth0 provides the ability to pass on username and password for authentication but it is def not recommended. This posses a security risk of logging creds. To pass on username/password your client needs to capture the creds first which means the app capturing the username/password could log credentials before passing it on to Auth0.

The recommendation here would be to use universal login flow (redirection). Your scenario looks like to be B2B. So your customers > users will use your app which will authenticate via Auth0. Is that the case ? If so, then you could use organizations.

Thanks
Jeff

2 Likes
3

Hi, thank you for your reply :slight_smile:

The use case is this: we have a web application (SPA) which talks to our API (resource server). In this case, we use the standard universal login flow as you recommended. User is redirected to tenant.auth0.com, logs in and is redirected back to our web. This works fine.

But, some users actually want to write a CLI script that does something with our API. No browser involved, just some CLI script or CRON job that communicates with our resource server. Hence we want to let them fetch ID and access token from Auth0, which they can use when communicating with our API. Hence the password-realm example I posted above.

What is the best way to achieve this if not the password-realm?

4

Hi @lukashavrlant

In your case, it is recommended to use Machine 2 Machine flow. here are some references:

Hope it helps

regards
Jeff

1 Like
5

Is it possible to also get ID token with this flow?

6

Hi @lukashavrlant

No, Id tokens are meant for authentication of a user not for a CLI or machine tasks

Can the CLI or client apps pass user_id or whatever you are after from client apps as POST payload to your API’s?

Thanks
Jeff

7

Ok, to make things more complicated, I’ll describe the whole flow. In the SPA, we redirect the user to tenant.auth0.com, they log in and they are redirected back to our app. At this point, we take the auth0 ID token, we send it to “our authorization server” and based on user_id from the ID token we generate whole new access token signed by our secret. This access token is used to access our resource servers. Our resource servers do not accept any auth0 tokens. We use just the ID token for the authentication part. Both auth0 tokens are basically forgotten at this moment. That is why we need our users to be able to fetch ID token from auth0 so they can send it to “our authorization server” and exchange it for the final access token. We can use other flow but this would not require adding any functionality to our apps.

8

If we go back to the previous question: is it safe to share the client secret to our customers? Can they do something with it other than logging in via username/password? Something dangerous…?

9

Hi @lukashavrlant

If users are getting redirected back to your app why the customers need to have client secrets ? I am trying to understand how the customers will get users passwords to get token from password grant ? Are they capturing the username/password from their users ?

1 Like
10

I am talking about the use case when CLI or CRON is involved. If we don’t use machine2machine flow but we use the password-realm instead, they have to send username, password and client secret (as I wrote in the first post here: What is the purpose of a client secret?)

So my question is: if we share the client secret to our customers, can they do any harm with it to us? I understand that the password-realm is not recommended but it seems it’s the only way unless we want to rewrite parts of our application (which we don’t want to for now).

In other words: we want to allow our users to get ID token via http://auth0.com/oauth/grant-type/password-realm using their username/password and I’m asking how dangerous is to share a client secret with them?

11

hi @lukashavrlant

It is fine to create a separate application for your client (per client) and share your client’s secret with your customers as long as you:

  • Restrict their applications/clients to connections only as required.
  • Only give scopes/permissions as required.
  • Make sure their applications have NO access to management API otherwise they can do admin tasks on your tenant.

Hope this helps

Regards
Jeff

2 Likes
12

Thank you, that was helpful! :slight_smile:

13

One final question: how can we make sure the application has no access to management API? What should we disable or what should we check to be absolutely sure?