Perhaps we can say that installed client apps can have client
secrets after all, by calling the authorization server and asking
for a new client_id and client_secret assignment for that
particular app-install.
Any thoughts on that?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to
the death your right to say it." - S. G. Tallentyre
On Sat, May 29, 2010 at 5:21 AM, Andrew Arnott
<andrewarn...@gmail.com <mailto:andrewarn...@gmail.com>> wrote:
Hi Dirk,
If you eradicated access token secrets in favor of signing
with client secrets, how would installed apps, where the
client secret is worthless and usually blank,
authenticate/sign their own requests?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend
to the death your right to say it." - S. G. Tallentyre
On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz
<balf...@google.com <mailto:balf...@google.com>> wrote:
Hi guys,
at today's interim meeting, we were discussing Brian
Eaton's proposal for OAuth signatures. He was proposing a
mechanism that would (1) do away with base string
canonicalization, (2) allow for symmetric and public
keys, and (3) allow for extensibility.
He got homework from the group to prove the feasibility
of his proposal by showing a couple of implementations.
In this post, I would like to introduce another
improvement of the OAuth 2 signing mechanism, one which
is orthogonal to Brian's proposal (i.e., it would work
both with the signing mechanism in the current spec, as
well as with Brian's signature mechanism). The goal of my
proposal is twofold:
- it simplifies the spec. It will become more readable
and therefore easier to implement
- it separates out the mechanisms for delegated
authorization and for integrity protection into two
independent pieces, which can be put together by Servers
and/or Clients like LEGO blocks.
Summary:
- use the client secret instead of the token secret for
signing PR access requests.
Long version of the proposal:
- remove all references to access tokens that are not
bearer tokens from the spec.
- stop calling the access tokens "bearer tokens". Call
them just "access tokens".
- remove all references to token secrets from the spec
- remove all parts of the spec that are of the kind "if
bearer_token then X, else Y", and replace them with X.
- delete section 5.3
- add a section called "Request Authentication" that goes
something like this:
"Servers may require that requests be authenticated by
the Client, so that presentation of the access token
alone is not sufficient to access a Protected Resource.
This has several use cases, including, but not limited
to, the following:
- Non-repudiation: high-security deployments may require
that requests be authenticated (signed) in a
non-repudiateable way[1]
- Access to protected resources is not protected by SSL,
so that access tokens may leak.
- End-to-end-integrity: even if SSL _is_ used, network
infrastructure may strip SSL protection before the
request reaches the protected resource. The protected
resource, however, may require end-to-end integrity.
If the Server requires that the Client authenticate PR
access requests, then the Client uses the following
mechanism to sign their HTTP requests: [...]"
Then, we basically drop the old Section 5.3 here (except
we use the client secret instead of the access token
secret). Eventually, instead of Section 5.3, we may have
Brian's new signature scheme section here, which would
add the option of public-key crypto[1], etc.
What do you guys think?
Dirk.
[1] Technically speaking, the goal of non-repudiation can
only be achieved once we have public-key crypto.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
