DynReg - 2. Client Metadata - Add client_type

[Nat Sakimura]

Probably good idea to have client_type in the metadata.

from http://qiita.com/TakahikoKawasaki/items/f2a0d25a4f05790b3baa

[Vladimir Dzhuvinov]

Hi Nat,

What is the intent to add client_type? Is it for convenience?

The OP can effectively infer the client_type when dealing with a registration request by checking for

"token_endpoint_auth_method" : "none"

(and the introspection and revocation auth method params, if they eventually get into the OIDC spec)

OIDC has also built upon OAuth in ways that make the delineation between public and confidential clients ambiguous. Consider the following client example, for a native or JS app:

• Has none as the token auth method
• Has registered a JWK set URI and is using signed authentication requests

[Takahiko Kawasaki]

Why do we have to infer client_type from other parameters instead of specifying its value explicitly?

Have we reached a consensus on rules as to how to infer client_type? Is it intuitive to infer client_type from the value of token_endpoint_auth_method and/or the registration status of a JWK set URI? Why do we have to rely on such a roundabout way?

As a matter of fact, in the second paragraph of RFC 6749, 2. Client Registration, "client type" is explicitly listed as an example of client properties for registration.

Client registration does not require a direct interaction between the client and the authorization server. When supported by the authorization server, registration can rely on other means for establishing trust and obtaining the required client properties (e.g., redirection URI, client type). For example, registration can be accomplished using a self-issued or third-party-issued assertion, or by the authorization server performing client discovery using a trusted channel.

The value of client_type is absolutely necessary when we implement OAuth 2.0 + OpenID Connect. I don't find any rational reason to avoid adding client_type to the client metadata.

[Vladimir Dzhuvinov]

Given the fact that the client type can be inferred from other parameters (token_endpoint_auth_method), I'm afraid that by adding it we introduce a redundant parameter.

This will also make processing of client reg requests harder for OP / AS servers. Consider that if token_endpoint_auth_method is left blank, the client registration endpoint should default it to client_secret_basic. But then, with a client_type with introduce another way to set intent. If one or the other is blank or set, what would should then the value of the other parameter become? I'm asking this simply for practical reasons :)

Section 2 from OAuth core does indeed say what you mention, but this text is not binding by downstream specs.

To ease inferring the client type, one could always create a bit of software code. Which is just a few lines. For example, we added an infer_type method to the Java object that represents the client registration:

http://static.javadoc.io/com.nimbusds/oauth2-oidc-sdk/5.5.1/com/nimbusds/oauth2/sdk/client/ClientInformation.html#inferClientType()

[Takahiko Kawasaki]

The same logic is true in the opposite direction. token_endpoint_auth_method can be inferred from client_type. From my viewpoint, ironically, the fact your implementation has added infer_type implies the need of client_type parameter.

The following is the current implementation of ClientInformation.inferClientType() method in oauth2-oidc-sdk.

public ClientType inferClientType() {

        // The client must by unambiguously public, else it is marked as confidential

        return secret == null
                && ClientAuthenticationMethod.NONE.equals(getMetadata().getTokenEndpointAuthMethod())
                && getMetadata().getJWKSetURI() == null
                && getMetadata().getJWKSet() == null
                ? ClientType.PUBLIC : ClientType.CONFIDENTIAL;
}

If client_type property existed, I would add an if block like below.

public ClientType inferClientType() {

        // If the client type is specified explicitly.
        if (clientType != null) {
            // We don't have to infer the client type. Let's use the explicit value.
            return clientType;
        }

        // The client must by unambiguously public, else it is marked as confidential

        return secret == null
                && ClientAuthenticationMethod.NONE.equals(getMetadata().getTokenEndpointAuthMethod())
                && getMetadata().getJWKSetURI() == null
                && getMetadata().getJWKSet() == null
                ? ClientType.PUBLIC : ClientType.CONFIDENTIAL;
}

In addition,

A developer can pre-generate a request object, sign and/or encrypt it using a client-side private key, and put it on a Web server. Then, his public client can point to the location of the request object by request_uri parameter when it makes an authorization request. In this case, the public client's JWK Set document containing the client-side public key has to be accessible from the authorization server so that the server can verify and/or decrypt the request object. Therefore, even a public client must be able to publish its JWK Set document.

The logic of inferClientType() does not allow public clients to publish JWK Set documents, but it is wrong.

[Vladimir Dzhuvinov]

The same logic is true in the opposite direction. token_endpoint_auth_method can be inferred from client_type.

Not really, because the nature of this mapping is not symmetrical. The exact auth method cannot be inferred from the client type. OIDC core (section 9) defines 3 other auth methods apart from the default basic.

As for the inferral logic in that piece of software, one cannot really argue whether it's right or wrong. Interpretation is quite open:

https://tools.ietf.org/html/rfc6749#section-2.1

The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. The authorization server SHOULD NOT make assumptions about the client type.

My understanding is that if a particular client instance cannot be authenticated by the AS / OP, even if its requests are signed, I would consider it a public client. The RFC seems to leave that up to implementers.

[Takahiko Kawasaki]

If interpretation is quite open, in other words, if how to infer the client type is up to implementors and a consensus on it cannot be reached, don't you think it is better to add client_type to the client metadata all the more?

[Nov Matake]

"token_endpoint_auth_method" seems enough to me.

If "token_endpoint_auth_method" isn't "none", the client is confidential, isn't it?

If dynreg endpoint can detect whether secred should be issued or not, do you need to know whether the client is public or confidential, not the access token is issued from token endpoint or authz endpoint?

[Vladimir Dzhuvinov]

If "token_endpoint_auth_method" isn't "none", the client is confidential, isn't it?

Yes, in that case the client is definitely considered confidential.

If dynreg endpoint can detect whether secred should be issued or not, do you need to know whether the client is public or confidential, not the access token is issued from token endpoint or authz endpoint?

By looking at the token_endpoint_auth_method and the optional request_object_signing_alg parameters, the dyn reg endpoint is quite able to determine whether a secret must be issued or not:

• If token_endpoint_auth_method is set to client_secret_basic, client_secret_post or client_secret_jwt
• If request_object_signing_alg is set to HS256, HS192 or HS512.

[Filip Skokan]

By looking at the token_endpoint_auth_method and the optional request_object_signing_alg parameters, the dyn reg endpoint is quite able to determine whether a secret must be issued or not:

• If token_endpoint_auth_method is set to client_secret_basic, client_secret_post or client_secret_jwt
• If request_object_signing_alg is set to HS256, HS192 or HS512.

Also:

• If id_token_signed_response_alg is set to HS256, HS192 or HS512
• If token_endpoint_auth_signing_alg is set to HS256, HS192 or HS512
• If userinfo_signed_response_alg is set to HS256, HS192 or HS512