Encrypting the token secret in self-contained tokens is the obvious solution, from my point of view. That's the way such things are handled in Kerberos.

Regarding client secrets: One of the major obstacles when using OAuth 1.0 in large deployments is the need for sharing client secrets between authz server and resource server. Overcoming that obstacle was an important requirement for OAuth2 from the beginning, expressed by a lot of people.

If you want to use client secrets (or privat keys) for the purpose, that's fine with me - as long as token secrets are supported as an alternative way of signing token-authorized requests.

regards,
Torsten.

Am 30.05.2010 18:45, schrieb Andrew Arnott:
The advantage over using token secrets as it seems to me is that neither auth server nor resource server need to store any issued access tokens because they could be self-describing and signed. By having token secrets I think storing every issued token at the auth server or resource server side is almost unavoidable. I say "almost" because theoretically the token secret could be encrypted and included in the token itself, such that only the auth/resource server could decrypt the secret, then use that secret to verify the signature. This is likely more trouble than it's worth for some applications.

I don't have a solution to the "avoid sharing client secret with resource servers" problem. Some good points were made I think in this thread about how that would need to be solved.
--
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 Sun, May 30, 2010 at 1:45 AM, Torsten Lodderstedt <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote:

    what is the advantage in comparison to a token secret?

    How do you want to propagate the client_id and secret to the
    resource servers?

    regrards,
    Torsten.


    Am 30.05.2010 um 03:27 schrieb Andrew Arnott
    <andrewarn...@gmail.com <mailto:andrewarn...@gmail.com>>:

    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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to