In the client apps case you use bearer tokens.
________________________________
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Andrew Arnott
Sent: Saturday, May 29, 2010 5:21 AM
To: Dirk Balfanz
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposal for factoring out request
signing in OAuth 2
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> 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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
