Subject: [OAUTH-WG] Oauth Server to Server

From: Antonio Sanso <[email-masked]>
Date: Tue, 24 Sep 2013 14:08:33 +0200

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

---

From: Brian Campbell <[email-masked]>
Date: Tue, 24 Sep 2013 06:35:29 -0600

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 <[email-masked]> wrote:

> 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.
>
> 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 )
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 24 Sep 2013 14:56:56 +0200

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 <[email-masked]> wrote:

> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking for?
> 
>

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 24 Sep 2013 07:57:36 -0700

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?

- cmort

On Sep 24, 2013, at 5:57 AM, Antonio Sanso <[email-masked]> wrote:

Hi Brian,

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 <[email-masked]>
wrote:

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 24 Sep 2013 17:17:17 +0200

Hi chuck,

On Sep 24, 2013, at 4:57 PM, Chuck Mortimore <[email-masked]> 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

---

From: Bill Mills <[email-masked]>
Date: Tue, 24 Sep 2013 08:22:51 -0700 (PDT)

So they are using client authentication as defined on OAuth 2 then?

On Tuesday, September 24, 2013 8:18 AM, Antonio Sanso <[email-masked]> wrote:
 
Hi chuck,

sure.

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

regards

antonio

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 24 Sep 2013 17:29:45 +0200

> So they are using client authentication as defined on OAuth 2 then?

good point indeed :) My main point is that all the pieces of the puzzle to solve this scenario are probably there beetwen the OAuth core the JWT and the JWT bearer token specifications but it would be tough to an OAuth newbie to figure out all this on his own….

regards

antonio

---

From: Phil Hunt <[email-masked]>
Date: Tue, 24 Sep 2013 09:05:17 -0700

Just looking at your subject line, and I may have this wrong but are you not asking about chaining? In server to server you need a way for the second server to accept a token from the first to propagate the authorization correct?

Phil

> On Sep 24, 2013, at 5:08, Antonio Sanso <[email-masked]> wrote:
> 
> Hi *,
>

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 24 Sep 2013 09:56:17 -0700

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 <[email-masked]> wrote:

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

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 24 Sep 2013 20:38:54 +0200

Hi Chuck,

On Sep 24, 2013, at 6:56 PM, Chuck Mortimore <[email-masked]> wrote:

> 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

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 24 Sep 2013 11:43:47 -0700

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 <[email-masked]> wrote:

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

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 26 Sep 2013 13:34:26 +0100

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

2-way TLS and Resource Owner Password Credentials should be secure 
enough, right ?

Cheers, Sergey

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Sep 2013 09:40:20 -0400

From what I read, it sounds like you want either the assertion flow 
(which is defined in extensions) or the client credentials flow (not the 
resource owner password flow). In either of these, the client 
authenticates on its own behalf and gets a token directly with no user 
involved, and both are fully specified.

  -- Justin

---

From: Todd W Lainhart <[email-masked]>
Date: Thu, 26 Sep 2013 10:54:46 -0400

(which is defined in extensions) or the client credentials flow (not the 
resource owner password flow).

I thought the same re "client credentials flow", but on a quick reading of 
Google's spec, their impl also allows for impersonation, assuming that the 
client has been registered to allow such (unclear if the original poster 
also wanted this functionality).  We have a similar feature in our impl - 
client creds flow w/ impersonation (with supporting registration).

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:   Justin Richer <[email-masked]>
To:     Antonio Sanso <[email-masked]>, 
Cc:     "[email-masked] WG" <[email-masked]>
Date:   09/26/2013 09:41 AM
Subject:        Re: [OAUTH-WG] Oauth Server to Server
Sent by:        [email-masked]

  -- Justin

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 27 Sep 2013 10:33:13 +0200

> 2-way TLS and Resource Owner Password Credentials should be secure 

secure is secure what I do not like of that flow though is the fact that the resource owner should give the AS username/password to the client

regards

antonio

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 27 Sep 2013 10:35:08 +0200

On Sep 26, 2013, at 3:40 PM, Justin Richer <[email-masked]> wrote:

> (which is defined in extensions)

I do agree the assertion flow + JWT bearer token will suffice

> or the client credentials flow

not too sure about this though since it requires human interaction on input username/password

regards

antonio

> (not the

---

From: Sergey Beryozkin <[email-masked]>
Date: Fri, 27 Sep 2013 09:48:40 +0100

> secure is secure what I do not like of that flow though is the fact that the resource owner should give the AS username/password to the client
Sure I agree to some extent; FYI, the integration scenarios I've been 
aware of (ex, Big Query server to server with no user having to sit in 
front of the application, with the application design being driven from 
a tooling studio) would work IMHO perfectly well with RO grant due to 
the clients & resource owners being most likely in the same 
organization; working with a json token complicates things quite a lot 
in our particular case :-), obviously it is more secure on the Web at 
large,

Cheers, Sergey

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 27 Sep 2013 10:55:48 +0200

Thanks Chuck

On Sep 24, 2013, at 6:56 PM, Chuck Mortimore <[email-masked]> wrote:

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

I am reading carefully the 2 specs now (assertion and JWT bearer) and will try to provide my feedback :)

A couple of (early) consideration so far:

- in order for somebody to easily achieve/understand what is clearly described in http://login.salesforce.com/help/doc/en/remoteaccess_oauth_jwt_flow.htm only reading the IETF materials is needed to read 3 specs (OAuth Core, Assertion spec and JWT bearer). IT would be nice for example if the JWT bearer spec would add some more hands on example (I do not know if it is possible though)
- The assertion spec (http://tools.ietf.org/html/draft-ietf-oauth-assertions-12) contains terms like and include those terms in the flow charts as Relying party , Token Service that I know are really common in the Identity jargon (or Open ID Connect specs) but this nomenclature doesn't match with the OAuth core specs (namely RFC 6749)

just my 0.02 $ so far (more to come)

regards

antonio

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 27 Sep 2013 11:44:57 +0200

> not too sure about this though since it requires human interaction on input username/password

ops apologies you are off course right. I wrongly mixed the client credentials flow with the implicit grant (sometime also called client-side... :s)

regards

Antonio