[Openid-specs-ab] Asymmetric client authentication and Question about secret_type: JWT

[Edmund Jay]

This discussion has brought into attention that the secret_type parameter that 
is defined in Section 3.1.5 of the superseded HTTP-Redirect Binding spec has 
been inadvertently left out of the current Messages and Standard specs.

This parameter is defined for the Token endpoint as a way for clients to 
authenticate using asymmetric keys.  OAuth 2.0 only defines symmetric client 
secrets for the Token endpoint.

The text for the section is as follows :


Upon receipt of the "code", the           Client requests an Assertion that 
includes the "access_token"           and other variables. To obtain the 
assertion, the client send the           following parameters via HTTPS POST to 
the token endpoint using application/x-www-form-urlencoded format           in 
the HTTP request entity-body:  

grant_type
>REQUIRED. A string               "authorization_code". 
>code
>REQUIRED. The authorization code received               from the authorization 
>server. 
>
>client_id
>REQUIRED. The client_id of the RP. 
>secret_type
>OPTIONAL. Specifies the client               authentication type which 
>determines how the client_secret parameter is interpreted. It               can 
>be one of "basic" or "JWT". Defaults to "basic". 
>
>client_secret
>OPTIONAL. Client Secret. If the               secret_type is "basic", send the               
>pre-shared secret. If the secret_type is "JWT",               send the compact 
>serialization of the JWT [JWT] Signature over the 'code'. 
>

Andreas says that this is not enough information for implementation.

It was decided that the text should be put back into Messages and Standard.
We can expand the Token endpoint section to talk a little bit more about client 
authentication and the differing types (symmetric vs asymmetric).
The secret_type parameter will explain the need for the JWT as a method to 
indicate asymmetric client authentication.
The client _secret parameter will be expanded to include where pre-shared 
secrets come from and the JSON inputs for the JWT asymmetric signature.

The JSON input should be something like the following :

{
    "code" : "some code value",
    "aud" : "blah blah",  // audience
    "iss"   : "blah blah", // issuer
    "exp"  : "blah blah", // expiration
    "typ"  : "blah blah", // type
    "nbf"  : "blah blah", // valid not before
    "iat"  : "blah blah"  // issued at
}

The last 6 claims are OPTIONAL JWT parameters, but maybe we should REQUIRE it to 
make it more secure.
Since this is for the Token endpoint which could accept refresh access tokens 
also, we should probably make "refresh_token" a member also.


We should probably also change the Client Registration spec to allow clients to 
register asymmetric client secrets.
It will contain the jku (JSON Key URL) and x5u (x509 public key URL) parameters 
as defined in JWS or their actual values.

Any thoughts or feedback? Thanks.

-- Edmund








________________________________
From: John Bradley <ve7jtb at ve7jtb.com>
To: Andreas Åkre Solberg <andreas.solberg at uninett.no>
Cc: openid-specs-ab at lists.openid.net
Sent: Thu, August 25, 2011 9:21:35 AM
Subject: Re: [Openid-specs-ab] Question about secret_type: JWT

Yes if we keep tis we need to have:
aud
iss
exp 
and perhaps a specific typ 

It should probably be part of a profile for using openID Connect with asymmetric 
signatures as an extension.

John B.
On 2011-08-25, at 3:53 AM, Andreas Åkre Solberg wrote:


>
>On 25. aug. 2011, at 06:39, John Bradley wrote:
>
>Yes the idea is to use JWS to avoid directly disclosing the secret as is done 
>with basic in the symmetric key case.
>>
>>
>>OAuth dosent define a asymetric authentication to the token endpoint.
>>
>>
>>The plan was to define a JWT with a single claim of code that would be signed by 
>>the RP.

OK.

My main point is that, I think there are security issues with that, unless you 
also require or reccomends that the JWT iss and aud headers are present (I don't 
think they are in the JWT spec).
>
>
>Andreas_______________________________________________
>Openid-specs-ab mailing list
>Openid-specs-ab at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110826/cee72e08/attachment.html>