[Authorization Code] - getClient method has dual role depending on which method is using.

[Streeterxs]

Hello,

I'm trying to implement authorize({authenticateHandler:{handler: Function}) and is needed at here to add client_id to the body or to the query parameters, but clientSecret isn't required.

This enters in a conflict for my previously coded getClient({clientId, clientSecret}) for the token method at here;

Is this meant to have that behavior? Shouldn't getClient always receive id and secret? Should my getClient accept nullable clientSecrets?

Sorry if I'm wrong or, but I found this behavior weird

UPDATE -

Reading at Oauth2's RFC I found that the client only adds his ID for identifier purposes, and the client will be authenticated only on step D as stated here : " (D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification. "

So the problem for me with authorize()'s getClient method, is that this method is exactly the same in token() which does have AUTHENTICATION purposes of the client.

My proposes:

• Model accept another method to identify the client and not authenticate him (like identifyClient)

[whatwewant]

@Streeterxs i solved the same problem https://github.com/oauthjs/node-oauth2-server/issues/651#issuecomment-686633842 , hope it could be helpful for you

[Streeterxs]

@whatwewant Thank you.

I already work arround it too, by the way I liked your solution too. But I still think it would make more sense if we split authenticate/identify client concerns into two differents methods for the model. I think that way the package would be more complete, more readable and would have a better syntax logic

[Siedlerchr]

I have the same problem, I cannot do the Basic Auth because that would require exposing my client_secret in my web/mobile app. The spec says it's only for condifential clients, However, web apps are considered public clients.

If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1. https://tools.ietf.org/html/rfc6749#section-4.1.3

I suggest it makes sense to addtionally check for the presence of the code field

[perry-mitchell]

The client secret should not be sent in the initial login request, as this would expose it in the URL/query string. It's only required for the token exchange which occurs afterwards:

Namely point 3 does not need the secret, but 6 does.

This sounds like a bug/limitation of this library in that it doesn't offer more information to the getClient method. Imo it should also receive some kind of information pertaining to the request, like grantType. Having the grant type would solve this as you could handle a null client secret based upon which grant is being performed.