Re: [OAUTH-WG] Oauth Server to Server

[Chuck Mortimore <[e-mail]>]

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


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
>
>
>