Re: [OAUTH-WG] Oauth Server to Server

[Chuck Mortimore <[e-mail]>]

Open to how it can be improved.   What information do you think would be
helpful?   ( we may be too close to the situation to know what's missing )


On Tue, Sep 24, 2013 at 11:38 AM, Antonio Sanso <[e-mail]> wrote:

> Hi Chuck,
>
> On Sep 24, 2013, at 6:56 PM, Chuck Mortimore <[e-mail]>
> wrote:
>
> What you're describing is exactly what the JWT bearer flow specs out
>
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer
>
> We've got the exact same flow, and there are other implementations out
> there.
> http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm
>
>
>
> thanks this is indeed the same :) What it looks to me though is that the
> information contained in the second link you shared (
> http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm)
> are complementary to the jet bearer spec draft.
>
> People that will only read that spec would need to figure out all on their
> own . Is there any chance the oauth bearer draft will cover the actual use
> case as well or it would be too much ?
>
> Regards
>
> Antonio
>
>
>
> On Tue, Sep 24, 2013 at 8:17 AM, Antonio Sanso <[e-mail]> wrote:
>
>> Hi chuck,
>>
>>
>> On Sep 24, 2013, at 4:57 PM, Chuck Mortimore <[e-mail]>
>> wrote:
>>
>> I'm not sure I understand your point here.   I don't believe there is
>> anything custom or special about the google implementation here vs JWT.
>> It looks identical to our implementation.
>>
>> Can you elaborate?
>>
>>
>> sure.
>>
>> What is novel IMHO in the Google approach is not the bearer format , that
>> is still JWT (or JWS in this case) but the overall scenario.
>>
>> As I see OAuth 2 is really good to cover use cases where there is human
>> interaction (so an user namely the resource owner can provider username and
>> password to the AS but not to the client and get back the Bearer Token).
>> This is obviously covered from [2] and [3] namely Authorization Code
>> Grant and Implicit grant flow.
>>
>> When there is not human interaction involved what RFC6749 offers is the
>> already cited Resource Owner Password Credentials Grant that IMHO is a no
>> go since it required the resource owner to share his password with the
>> client.
>>
>> The way as Google offers to solve the same situation (namely obtain , or
>> create in this case, a bearer token without having the resource owner
>> password) is using asymmetric cryptography. What is happening is that
>> quoting
>>
>> "During the creation of a Service Account, you will be prompted to
>> download a private key. Be sure to save this private key in a secure
>> location. After the Service Account has been created, you will also have
>> access to the client_id associated with the private key."
>>
>> An alternative mentioned from John Bradley previously is that clients can
>> securely generate key pairs but in terms of security would be identical.
>>
>> I hope is a bit clearer now  :)
>>
>> regards
>>
>> antonio
>>
>>
>> [2] http://tools.ietf.org/html/rfc6749#section-4.1
>> [3] http://tools.ietf.org/html/rfc6749#section-4.2
>>
>>
>> - cmort
>>
>> On Sep 24, 2013, at 5:57 AM, Antonio Sanso <[e-mail]> wrote:
>>
>> Hi Brian,
>>
>> thanks a lot for your pointer.
>>
>> What the custom Google flow provides more than the oauth jwt bearer draft
>> is IMHO an explicit way to build JWT without any 'human interaction' so a
>> server can handle the construction of an expired JWT bearer token on his
>> own.
>>
>> This can of course be figured out by any implementer (as the Google folks
>> obviously did) but it would be nice to provide this black on white on a
>> spec IMHO
>>
>> regards
>>
>> Antonio
>>
>>
>> On Sep 24, 2013, at 2:35 PM, Brian Campbell <[e-mail]>
>> wrote:
>>
>> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be
>> what you're looking for?
>>
>>
>> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso <[e-mail]> wrote:
>>
>>> Hi *,
>>>
>>> apologis to be back to this argument :).
>>>
>>> Let me try to better explain one use case that IMHO would be really good
>>> to have in the OAuth specification family :)
>>>
>>> At the moment the only "OAuth standard" way I know to do OAuth server to
>>> server is to use [0] namely Resource Owner Password Credentials Grant.
>>>
>>> Let me tell I am not a big fun of this particular flow :) (but this is
>>> another story).
>>>
>>> An arguable better way to solve this scenario is to user (and why not to
>>> standardise :S?) the method used by Google (or a variant of it) see [1].
>>>
>>> Couple of more things:
>>>
>>> - I do not know if Google would be interested to put some effort to
>>> standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
>>> - I am not too familiar with IETF process. Would the OAuth WG take in
>>> consideration such proposal draft??
>>>
>>> Thanks and regards
>>>
>>> Antonio
>>>
>>> [0] http://tools.ietf.org/html/rfc6749#section-4.3
>>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>