Subject: Re: [OAUTH-WG] Securing APIs with OAuth 2.0

From: Antonio Sanso <[email-masked]>
Date: Thu, 1 Mar 2012 12:41:59 +0000

Hi Pete

On Mar 1, 2012, at 3:44 AM, Pete Clark wrote:

> 2) Point me to an implementation of this flow (in any language) that I could use or port to PHP?  I've found some libraries for php but can't really tell, being new, if they offer the "client credentials" flow

In Apache Amber (OAuth protocol implementation in Java) [0] you might find something you can reuse.

Regards

Antonio

[0] http://incubator.apache.org/amber/

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 1 Mar 2012 04:20:39 +0000

I believe this one https://github.com/quizlet/oauth2-php is the most
up-to-date PHP library, although you might check around for forks of it
since I haven't checked up on it in a month or so.

Aaron Parecki

On Wednesday, February 29, 2012, Pete Clark wrote:

> Hey all, I've joined the list because I'd like to use OAuth 2 to implement
> security for a new set of REST APIs I'm developing for a client.  I'm
> coding with PHP, but my questions are more general.  Right now, there will
> be only one web site that uses the APIs, in a server-to-server fashion, and
> currently we don't have a need for a third party application to gain access
> to user data, such that a user would need to authorize that app.  We do,
> however, want to have that ability down the road.  My question is, can I
> still use OAuth 2 in some way to implement our first phase?  From what I've
> read, it seems like the "client credentials" flow is the one I want to use
> for now.  Can someone:
>
> 1) Confirm that that's what I should use for this first phase?
> 2) Point me to an implementation of this flow (in any language) that I
> could use or port to PHP?  I've found some libraries for php but can't
> really tell, being new, if they offer the "client credentials" flow
> 3) Answer one more question.. Will using the client credentials flow now
> allow me to move to one of the user-authorizes-external-app flows down the
> road without having to reimplement or throw away the client credentials
> flow code?
>
> I apologize for all the questions, but these would really help point me in
> the right direction.. Thank you for reading!
>
> Sincerely,
> Pete
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 1 Mar 2012 15:19:18 +0000

Aaron Parecki

On Thu, Mar 1, 2012 at 2:44 AM, Pete Clark <[email-masked]> wrote:

> [email-masked]

---

From: André DeMarre <[email-masked]>
Date: Thu, 1 Mar 2012 14:24:36 -0800

Pete,

Shane is right; the way you described your problem, the client
credential grant type may be appropriate. That's especially true if
the client will be accessing resources that don't necessarily belong
to specific users. But if the client (web site) will be using the API
(OAuth auth/resource server) to access user-specific resources, then
the authorization code grant type is a better fit. It doesn't matter
that the OAuth server trusts the client without needing user
authorization.

The authorization code flow offers a solution for user identification
that is absent in the client credential flow. In other words, even
though the OAuth server trusts the client and will comply with all API
requests, how is the client x supposed to identify a user so it can
request the right resource from the resource server?

By using an authorization code grant, the client can acquire an access
token that is bound to a specific user. This is makes the
authorization code flow suitable for single sign-on implementations,
whereas the client credential flow is not appropriate for user
authentication.

Don't worry about the fact that the client does not need to be
authorized by the user. You can still use the authorization code flow,
and the authorization server will not need to prompt the user for
authorization because you will have pre-authorized the client for all
users.

As an added bonus, this sets you up perfectly for when you add new
clients which are not pre-authorized and need user authorization.

I hope that helps.

Regards,
Andre DeMarre

On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden <[email-masked]> wrote:
> 1. Yes, client credentials sounds right for what you described. Think of it
> as lightweight b2b authentication in that sense (but two steps - one to get
> a token, and another to use it).
> 2. Can't help you with source - but do have a product-based solution :)
> 3. Absolutely it should for the resource server, but the answer may depend
> have same dependency on the implementation you use.
>
> Regards,
> Shane.
>
>
>
> From:   Pete Clark <[email-masked]>
> To:     "[email-masked]" <[email-masked]>
> Date:   29/02/2012 06:50 PM
> Subject:        [OAUTH-WG] Securing APIs with OAuth 2.0
> Sent by:        [email-masked]
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 2 Mar 2012 10:26:03 -0500

+1 to André's suggestion below.

If you find that you're going to have to add a field to your API to 
indicate the userID along with a two-legged transaction, you're likely 
doing things wrong.

We've used the auto-approve method below for several applications, and 
users don't seem to know or care what's really happening. They show up 
to the client app, they see a little waiting screen the first time 
through, and then it works. That is to say, it's nearly as transparent 
as a two-legged scenario but with better security and flexibility aspects.

The two-legged approach works best when:
   1) There's no user involved in the transaction at all (traditional 
system-to-system data exchange)
   2) You *can't* have the user present on any part of the transaction 
(it must work fully back-channel)

If you can count on the user being there at any point, even to just kick 
things off, then the code flow is likely more like what you're after.

  -- Justin

On 03/01/2012 05:24 PM, André DeMarre wrote:
> On Wed, Feb 29, 2012 at 6:59 PM, Shane B Weeden<[email-masked]>  wrote:
>> From:   Pete Clark<[email-masked]>
>> To:     "[email-masked]"<[email-masked]>

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 05 Mar 2012 12:04:43 +0000

Hi,
> authorization because you will have pre-authorized the client for all

Can the authorization server return a (pre-authorized) token immediately 
in this case, despite the fact the client is specifying 
"response_type=code" ?
If the authorization code, to be exchanged later for this token, has to 
be returned, how reasonable is it to expect that the authorization code 
will be bound to the pre-authorized access token (example, the access 
token's key/id will be returned as the authorization code) ?

I suspect it may not be a good idea given the spec is saying the 
authorization code should be short-lived, thus the codes and actual 
tokens will have different life-cycles, however the fact the end user 
has pre-authorized the client adds some uncertainty to it...

thanks, Sergey

---

From: Justin Richer <[email-masked]>
Date: Mon, 5 Mar 2012 09:14:18 -0500

> Can the authorization server return a (pre-authorized) token 
> immediately in this case, despite the fact the client is specifying 
> "response_type=code" ?
No -- the server MUST return an authorization code, even if there is no 
interaction beyond the user logging in (which may be SSO and therefore 
"invisible" to users). This code is bound to the user session and the 
client ID, and it needs to be presented in the back channel with the 
client's ID and secret, away from the user session. These two steps are 
what close the client-server-user triangle in a secure way so that no 
party knows more than they really need to. The Client Credentials flow 
and the Implicit flow collapse this triangle into a line in two 
different ways, both for different use cases and both have their 
tradeoffs. So if you want to get an access token from the authz endpoint 
directly, you use the implicit flow. It puts all of the weight onto the 
user agent, which sounds like the opposite of what you actually want to 
do here.

> If the authorization code, to be exchanged later for this token, has 
> to be returned, how reasonable is it to expect that the authorization 
> code will be bound to the pre-authorized access token (example, the 
> access token's key/id will be returned as the authorization code) ?
>

Again, no -- the code shouldn't have anything in it that ties it to the 
access token directly. If it did, then anybody intercepting just the 
code on the wire could guess the access token, which would make the auth 
code a pointless abstraction. The best way to deploy the authz code is 
to have a short, random, opaque blob that is one-time use and expires 
after a set amount of time, probably fairly short (on the order of 
minutes in most cases). Think of it as a one-time-password that is 
generated for the resource owner to give to the client on their behalf. 
Since it's a credential known to both the user agent and the client, you 
really, really don't want it to be copied from any other part of the flow.

  -- Justin

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 5 Mar 2012 17:35:19 +0000

> user agent, which sounds like the opposite of what you actually want to

OK

> really, really don't want it to be copied from any other part of the flow.

OK.

Thanks for the explanations so far. It's very helpful.

I'm prototyping the framework support for OAuth 2.0 and at this stage
I'm trying to figure out what exactly the runtime itself can do and what
has to be delegated to the custom code and thus how to design the api
the runtime and the custom code will use to communicate with each other.

Let me ask one more question, sorry if it's a silly one :-)

So suppose a given client has been pre-authorized by the end user.
Next, the client can get the pre-authorized token via the authorization
code flow or the implicit code flow (ignoring the client_credentials one
for the moment).

Does it make sense to restrict which flow a given pre-authorized token
can 'work' with ? Example, enforce that the pre-authorized token can
only be issued to the clients initiating an authorization code flow but
not to those trying an implicit one, or vice versa ?

The reason I ask is that I'm thinking that the entity representing an
access token should have a property indicating which grant type was used
for this token being created in the first place. So if such a token
were to represent the user pre-authorizing the client
and then eventually given to a client via the authorization code or
implicit code flow, then this token would actually need to
be cloned each time for a specific grant type property be set, and
this does not look optimal...

Cheers, Sergey

---

From: Justin Richer <[email-masked]>
Date: Tue, 6 Mar 2012 11:38:15 -0500

> the runtime and the custom code will use to communicate with each other.

Makes sense. It's often hard to figure out exactly where to draw the 
lines of abstraction for fundamental libraries like this.

> this does not look optimal...

Several implementations that I've seen do restrict the flows that a 
given client is allowed to do. Any time you have a privileged client, 
such as one that's been auto-approved, it makes even more sense to lock 
it down in other avenues. You don't have to encode it into the token or 
code, but of course if you have a structured token format you may do 
that. Note that with the code flow, you probably don't actually generate 
the token until the client shows up with a valid code and client 
id/secret, but that's really a runtime optimization that's going to be 
specific for your setup.

All you really need is a flag at your AS that ties the given client id 
to a set of allowable grant types. When the client shows up at the AS 
endpoints, you look up this flag based on the client ID and verify that 
the flow you're doing matches up with what's allowed by configuration.

  -- Justin