[OpenID] Does Application Type correspond to Client Type?
Torsten Lodderstedt
torsten at lodderstedt.net
Sun May 11 19:55:26 UTC 2014
Hi John,
> What is not possible without extending dynamic client registration are public clients that use a code grant_type.
> One of the main reasons for dynamic client registration is to eliminate the need for an AS to support public clients using the code grant_type.
sounds reasonable but where do I find this restriction in the specs?
regards,
Torsten.
> Am 11.05.2014 um 19:59 schrieb John Bradley <ve7jtb at ve7jtb.com>:
>
> This list is for general information about openID.
>
> The correct place to discuss deployment and interop issues and questions is OpenID Connect Interop
> That group/list has no IPR restrictions.
>
> For discussing errata or other issues with the Connect specifications the list is http://lists.openid.net/mailman/listinfo/openid-specs-ab.
> You must sign a non assert IPR agreement to contribute to the specification, as all the other WG participants have.
>
> The Connect WG page lists the links and other useful information http://openid.net/connect/
>
> The version of Dynamic Client registration being developed by the OAuth WG in the IETF based on the Connect specification can be discussed at:
> https://www.ietf.org/mailman/listinfo/oauth
>
> To your question Registration's application type is not the same as RFC 6749 Sec 2.1 Client Types.
>
> It is dynamic registration itself that allows a native app to be confidential so that section of RFC 6749 may be changed after the IETF approves dynamic client registration.
>
> That section also states
>
> A client may be implemented as a distributed set of components, each
> with a different client type and security context (e.g., a
> distributed client with both a confidential server-based component
> and a public browser-based component).
>
> Connect supports this with the hybrid response types.
>
> A Web application with a single client_id may contain both a public component and a confidential component.
>
> The element response_type determines the flows the client can preform.
>
> The default for that is the client can only preform the code flow and must use a client credential to authenticate itself to the token endpoint.
>
> The response types are a finer grained and imply public and private for the hybrid components.
>
> What is not possible without extending dynamic client registration are public clients that use a code grant_type.
> One of the main reasons for dynamic client registration is to eliminate the need for an AS to support public clients using the code grant_type.
>
> In any event we can continue this on one of the other lists.
>
> John B.
>
>> On May 11, 2014, at 6:56 PM, Takahiko Kawasaki <daru.tk at gmail.com> wrote:
>>
>> Thank you for your comment.
>>
>> If both native clients and web clients can be public or confidential,
>> application_type which is described in Client Metadata section of
>> OpenID Connect Dynamic Client Registration 1.0 is DIFFERENT from the
>> client type described in RFC 6749.
>>
>> Considering the following two points:
>>
>> (1) RFC 6749 (OAuth 2.0) requires a client type to be registered.
>> (RFC 6749, 2. Client Registration)
>>
>> (2) OpenID Connect Relying Party is a kind of OAuth 2.0 client app.
>> (OpenID Connect Core 1.0, 1.2. Terminology)
>>
>> there should be a client metadata entry to specify a client type (e.g.
>> client_type), and it should be treated separately from application_type.
>>
>> Information about Client Type (not Application Type) is really needed
>> to implement OAuth 2.0 authorization server correctly. Especially it
>> is needed to determine (1) whether client authentication is required
>> at the token endpoint (3.2.1. Client Authentication) and (2) whether
>> registration of redirect URIs can be omitted (3.1.2.2. Registration
>> Requirements).
>>
>> Without a client metadata entry to specify a client type, the default
>> value of client type cannot help but be left to implementations of
>> OpenID Connect Dynamic Client Registration 1.0.
>>
>> IMHO, if such an entry (e.g. client_type) should be added, 'public'
>> would be appropriate as the default value because 'client_secret' in
>> Client Registration Response is OPTIONAL.
>>
>> --
>> Best Regards,
>> Takahiko Kawasaki
>>
>>
>>
>>
>> 2014-05-11 5:54 GMT+09:00 John Bradley <ve7jtb at ve7jtb.com>:
>>> Native clients may also be confidential if they register a unique client_id and have a secret that is provisioned in registration or out of band in some way.
>>>
>>> Web includes both confidential and public types of clients.
>>>
>>> Client type web or native came from a number of IdP like Google who do not allow the same client_id to be used across different types of clients.
>>>
>>> The type of client restricts the type of redirect_uri that is allowed to be registered.
>>>
>>> All clients must register full redirect URI and the Authorization server must match the registered redirect_uri with the one in the request.
>>>
>>> The recent covert redirect furor and the consequences of Facebook not requiring it should go some way to explaining why registering redirect_uri is important.
>>>
>>> One reason for not allowing native_apps and back end Web servers to share a client_id is privacy. A user granting a app on there phone access to a API is not the same as
>>> granting a Web site access, and a user discovering that consenting to one automatically consented to the other may not be taken well.
>>>
>>> The reason for separating the two types of clients is both good security and good privacy policy.
>>>
>>> John B.
>>>
>>>
>>> On May 10, 2014, at 12:02 PM, Takahiko Kawasaki <daru.tk at gmail.com> wrote:
>>>
>>> > 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 authentication 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.
>>> >
>>> > --
>>> > Best Regards,
>>> > Takahiko Kawasaki
>>> >
>>> >
>>> > 2014-05-10 10:29 GMT+09:00 Takahiko Kawasaki <daru.tk at gmail.com>:
>>> >> Hello,
>>> >>
>>> >> I'm wondering whether this is the right place to ask my question.
>>> >> If not, please tell me so.
>>> >>
>>> >> I posted a question to StackOverflow, but no answer yet.
>>> >>
>>> >> http://stackoverflow.com/q/23557801/1174054
>>> >>
>>> >> My question is "Does Application Type (OpenID Connect) correspond to
>>> >> Client Type (OAuth 2.0)?" Could anyone give me an answer please?
>>> >> Below is the detail of the question.
>>> >>
>>> >> "OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata"
>>> >> has an entry named application_type, whose defined values are
>>> >> 'native' and 'web'.
>>> >>
>>> >> --- Excerpt from OpenID Connect Dynamic Client Registration ------
>>> >> 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"?
>>> >>
>>> >> --- Excerpt from RFC 6749 (OAuth 2.0) ----------------------------
>>> >> 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?
>>> >>
>>> >>
>>> >> --
>>> >> Best Regards,
>>> >> Takahiko Kawasaki
>>> > _______________________________________________
>>> > general mailing list
>>> > general at lists.openid.net
>>> > http://lists.openid.net/mailman/listinfo/openid-general
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20140511/b67ddf9d/attachment-0001.html>
More information about the general
mailing list