0

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.

  1. 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.

vietvoquoc
  • 813
  • 1
  • 10
  • 23
  • 1
    Your question is not very clear. You said yourself that you "use client id and client secret to get the access token", and then you ask why client secret is needed? – Evk May 24 '18 at 09:33
  • Yes i knew that I use client id and client secret to make it work. But just concern why do we need that kind of data? – vietvoquoc May 24 '18 at 09:41
  • That's the same as asking why you need to provide username and password to log in to stackoverflow. Why not just username, or even not provide any data at all and magically login? – Evk May 24 '18 at 09:42
  • 1
    Oh, you are right. I feel quite stupid when dived into "singing key" and "client secret" :). If in case we not need the client secret it mean every body knew the client id will request an access token to access our resource, right? And do you know how the client secret send to Auth server because i checked and saw it use the URL with raw client id and "nonce". Thanks. – vietvoquoc May 24 '18 at 09:54
  • Looks like your client app is a console app, you are using client credentials Oauth flow to obtain access tokens. Authorization server is validating client with a secret, obviously client has to send the secret to prove. – Jay May 24 '18 at 13:57

1 Answers1

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.

m3n7alsnak3
  • 3,026
  • 1
  • 15
  • 24
  • Hello, thank you for taking time to explain all of great informations for me :). I think you are missing a bit with this **In this cases, you receive an access token on behalf of the logged in user.**. Because using `implicit and Hybrid` do not return you an `access token` at all. I think these just return `a list of claims stored in **idsrv** cookie` for further process by developer, right? Just only `HybridAndClientCredentials` will return you an `access token` and `list of claims` and in this case we need to supply client secret explained by you which is very make sense! – vietvoquoc May 25 '18 at 03:10
  • I just change the `HybridAndClientCredentials` to `Hybrid` and just noticed that regardless of that change we still need to provide the client secret. I think in the docs the `hybrid` will use the `code` returned from `Auth server` to get the `access token and refresh token automatically`(quoted from docs: ` After successful validation of the response, the back-channel is used to retrieve the access and refresh token.`). So do you know why do we need to supply a client secret in this case because we have the code already? Thanks. – vietvoquoc May 25 '18 at 04:30
  • Actually hybrid and implicit return `access_token`, you just need to intercept on the right place, at the right time, to see it. The claims are part of a token, after all – m3n7alsnak3 May 25 '18 at 17:00