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.
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) ?
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...
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
thanks, Sergey
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 protected]>
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 protected]>
To: "[email protected]"<[email protected]>
Date: 29/02/2012 06:50 PM
Subject: [OAUTH-WG] Securing APIs with OAuth 2.0
Sent by: [email protected]
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 protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
