"OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata" has an entry named application_type, whose defined values are native and web.
application_type
OPTIONAL. Kind of the application. The default, if omitted, is web.
The defined values are native or web. Web Clients using the OAuth
Implicit Grant Type MUST only register URLs using the https scheme
as redirect_uris; they MUST NOT use localhost as the hostname. Native
Clients MUST only register redirect_uris using custom URI schemes or
URLs using the http: scheme with localhost as the hostname.
Authorization Servers MAY place additional constraints on Native
Clients. Authorization Servers MAY reject Redirection URI values
using the http scheme, other than the localhost case for Native
Clients. The Authorization Server MUST verify that all the registered
redirect_uris conform to these constraints. This prevents sharing a
Client ID across different types of Clients.
Do these defined values correspond to public and confidential described in "RFC 6749 (OAuth 2.0), 2.1. Client Types"?
OAuth defines two client types, based on their ability to
authenticate securely with the authorization server (i.e., ability to
maintain the confidentiality of their client credentials):
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
If not, why doesn't the specification (OpenID Connect Dynamic Client Registration 1.0) have an entry to specify a client type? Is there any way to specify a client type (public or confidential) at the client registration endpoint?
OAuth 2.0 is designed only for authorization, for granting access to data and features from one application to another. OpenID Connect (OIDC) is a thin layer that sits on top of OAuth 2.0 that adds login and profile information about the person who is logged in.
OpenID Connect (OIDC) is an open authentication protocol that works on top of the OAuth 2.0 framework. Targeted toward consumers, OIDC allows individuals to use single sign-on (SSO) to access relying party sites using OpenID Providers (OPs), such as an email provider or social network, to authenticate their identities.
OpenID and OpenID Connect are both for authentication, not for authorization. The two activities are distinct. OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol. More explanations in this answer.
For example - IdentityServer4 which is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core.
If "Native Clients" in "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata" means "native application" in "RFC 6749 (OAuth 2.0), 2.1 Client Types" (yes it apparently does), Native Clients are always public clients.
If "Web Clients" in "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata" means "web application" in "RFC 6749 (OAuth 2.0), 2.1 Client Types" but does not include "user-agent-based application", Web Clients are always confidential clients.
Using the above interpretation, application_type=native and application_type=web correspond to public and confidential, respectively.
However, the requirement of application_type:
Web Clients using the OAuth Implicit Grant Type MUST only
register URLs using the https scheme as redirect_uris; they
MUST NOT use localhost as the hostname. Native Clients MUST
only register redirect_uris using custom URI schemes or URLs
using the http: scheme with localhost as the hostname.
is irrelevant to whether or not clients are "capable of maintaining the confidentiality of their credentials" (from RFC 6749). In other words, redirect URIs are irrelevant to how to authenticate clients. Therefore, it sounds to me that Application Type and Client Type are different concepts.
It is weird that all OAuth 2.0 clients must comply with either of the 'redirect_uris' requirements (one is for Web Clients and the other is for Native Clients), so probably it is inappropriate that 'web' is used as the default value when application_type is omitted. IMHO, neither of 'native' nor 'web' should be assumed when application_type is omitted. But, I may be missing something. Is there any reason to impose the 'redirect_uris' requirements on all OpenID Connect clients?
Anyway, my conclusion is that Application Type and Client Type are different. And I hope that client_type (public or confidential) is added to the list of Client Metadata and that neither of 'native' nor 'web' is used as the default value when application_type is not contained in client registration requests.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With