How client secret help in case of creation/validation of identityserver4?

Question

I tried the IdentityServer4 with ClientSecret and using access token to access Web API. It worked super cool but there is one thing bother me now. For me the process flow like these:

1. Client(Console application in my case) use client id and client secret to get the access token from /connect/token path which in turn getting from /.well-known/openid-configuration path.
2. Auth server validate and sign the token using temporary signing key - private key(I using developer temporary signing key).
3. Resource server getting the public key from ./well-known/openid-configuration to validate the access token. I refer from this

The Authorization Server will sign tokens with a key. Resource Server(s) should verify that the token's integrity with a key. Together they form an asymmetric (e.g. public/private) key pair. By default IdentityServer will publish the public key for verifying tokens on the /.well-known/openid-configuration endpoint.

4. Resource server return 401 status code or appropriate data whether the access token validated or not.

So my question is that because the signing access token and validating it using only the asymmetric key. Why do we need the client secret? And if we need it, where the client secret will be send through the authorization process?

Sorry for bad English :) Thanks.

Answer 1

I'll try to clear up the things a bit.

In your case, your client is a console app, which means that you need the client credentials grant type. According to the documentation:

This is the simplest grant type and is used for server to server communication - tokens are always requested on behalf of a client, not a user.

So you are receiving an access token on behalf of the client itself (your console app). And:

The client typically has to authenticate with the token endpoint using its client ID and secret.

And if you think about it, it actually makes sense - the client ID itself is not enough (like mentioned in the comments - you can't login to a site only with a username, you also need a password).

Now, when using some of the grant types, that require user credentials (Implicit, Hybrid) then you don't need to specify the client secret (when making the request), but this is because the user enters his username and password.

In this cases, you receive an access token on behalf of the logged in user.

PS: Just as and FYI - in your console app, you can also receive an access token on behalf of the user, but you need to switch your approach from client credentials grant type, to resource owner password, and when making the request to the token endpoint, you need to specify the username and the password.