[Openid-specs-ab] token_endpoint_auth_method Registration example error?
Justin Richer
jricher at mitre.org
Wed Jan 23 17:42:55 UTC 2013
All of that I agree with. Question remains if the server, in its
response to the client, wants to tell the client it has several of the X
options found in discovery.
-- Justin
On 01/23/2013 12:36 PM, Mike Jones wrote:
> I agree they're complimentary.
>
> Discovery tells the client what the server can do. It uses that
> information to pick the option to use that will work for both of them,
> then registers with that option.
>
> -- Mike
>
> ------------------------------------------------------------------------
> From: Justin Richer
> Sent: 1/23/2013 9:28 AM
> To: Mike Jones
> Cc: John Bradley; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] token_endpoint_auth_method Registration
> example error?
>
> Not all clients can necessarily use all forms of auth that a server
> supports, so I see the two values as complimentary.
>
> -- Justin
>
> On 01/23/2013 12:14 PM, Mike Jones wrote:
>>
>> The server expresses what the client should do in the discovery phase
>> – not during registration. See the
>> “token_endpoint_auth_methods_supported” discovery result parameter in
>> http://openid.net/specs/openid-connect-discovery-1_0-12.html.
>>
>> -- Mike
>>
>> *From:*John Bradley [mailto:ve7jtb at ve7jtb.com]
>> *Sent:* Wednesday, January 23, 2013 9:02 AM
>> *To:* Justin Richer
>> *Cc:* Mike Jones; openid-specs-ab at lists.openid.net
>> *Subject:* Re: [Openid-specs-ab] token_endpoint_auth_method
>> Registration example error?
>>
>> Like discovery the response could be multi value. However the client
>> souls only register one value if it wants to restrict what the server
>> accepts for that client_id.
>>
>> Sent from my iPhone
>>
>>
>> On 2013-01-23, at 4:33 PM, Justin Richer <jricher at mitre.org
>> <mailto:jricher at mitre.org>> wrote:
>>
>> But now that the server responds with the current configuration,
>> it's no longer just about client preference but also about the
>> server expressing to the client what it should do. So if a client
>> gets a client_secret, and the server is OK with it using basic,
>> post, or jwt with that secret, how can the server tell the client
>> this?
>>
>> The simplest thing is to keep it a single value as it is now, but
>> that's (as always) a tradeoff between flexibility and complexity.
>>
>> -- Justin
>>
>> On 01/23/2013 11:28 AM, John Bradley wrote:
>>
>> If you want a client to authenticate multiple ways just don't
>> register a prefrence.
>>
>> This was intended to prevent IdP from accepting weaker
>> methods of authentication from attackers. If you are not
>> doing that then the client should be able to use anything the
>> server supports.
>>
>> Now if the client doesn't register a public key then some
>> methods will fail, but that is a client decision.
>>
>> I think trying to say I only want to use 2 of the 5 available
>> methods is overkill.
>>
>> The client should just pick the one it is going to use.
>>
>> If it really needs two methods maybe it is really two clients
>> and somebody is fudging things a bit.
>>
>> John B.
>>
>> On 2013-01-23, at 4:18 PM, Justin Richer <jricher at mitre.org
>> <mailto:jricher at mitre.org>> wrote:
>>
>>
>>
>> Actually come to think of it, why wouldn't a client be able
>> to do both client_secret_basic and client_secret_post to a
>> server that supports them? It's the same info presented in
>> *almost* the same way.
>>
>> This combination may be the exceptional case, though, as the
>> other types (client_secret_jwt,private_key_jwt, or even
>> "none" that OIDC hasn't adopted yet) aren't particularly
>> mutually compatible.
>>
>> -- Justin
>>
>> On 01/23/2013 10:53 AM, Justin Richer wrote:
>>
>> OK, thanks for catching that. I'll file a bug against
>> Oauth2 Dynreg as well (which has the same examples). John
>> is right that it is defined as a single value and the
>> examples are off.
>>
>> -- Justin
>>
>> On 01/23/2013 10:03 AM, Mike Jones wrote:
>>
>> That’s what I thought. Thanks for confirming.
>>
>> -- Mike
>>
>> *From:*John Bradley [mailto:ve7jtb at ve7jtb.com]
>> *Sent:* Wednesday, January 23, 2013 7:02 AM
>> *To:* Mike Jones
>> *Cc:* openid-specs-ab at lists.openid.net
>> <mailto:openid-specs-ab at lists.openid.net>
>> *Subject:* Re: [Openid-specs-ab]
>> token_endpoint_auth_method Registration example error?
>>
>> The server may support multiple methods, but the
>> client MUST only register one, so it shouldn't be
>> multi value for simplicity.
>>
>> If you need two auth methods they should be different
>> client_id.
>>
>> This is intended mostly to enhance security and
>> prevent a server from taking client_secret_basic from
>> an attacker when the real client is using
>> private_key_jwt.
>>
>> John B.
>>
>> On 2013-01-23, at 9:07 AM, Mike Jones
>> <Michael.Jones at microsoft.com
>> <mailto:Michael.Jones at microsoft.com>> wrote:
>>
>>
>>
>>
>> Registration contains the following definition:
>>
>> token_endpoint_auth_method
>>
>> OPTIONAL. Requested authentication method for the
>> Token Endpoint. The options
>> areclient_secret_post,client_secret_basic,client_secret_jwt,
>> andprivate_key_jwt, as described in Section 2.2.1 of
>> [OpenID.Messages]. Other Authentication methods may
>> be defined by extension. If unspecified or omitted,
>> the default isclient_secret_basicHTTP Basic
>> Authentication Scheme as specified in Section 2.3.1
>> of [RFC6749].
>>
>> It later uses “token_endpoint_auth_method” in two
>> example result values in this manner:
>>
>> "token_endpoint_auth_method":
>>
>> "client_secret_basic client_secret_post",
>>
>> This looks like a bug to me, since the string appears
>> to be trying to contain multiple values.
>>
>> Thus, I’m changing the string used to just
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130123/54423864/attachment.html>
More information about the Openid-specs-ab
mailing list