Re: [OAUTH-WG] OAuth2 Implementation questions (client secret andrefresh tokens)

[Torsten Lodderstedt <[e-mail]>]

Hi Dave,

there has been a long debate about native client security and you can 
also find a comprehensive analysis in the security document.

It's just a fact that such clients cannot reliably be authenticated in a 
public environment (even if malicious clients can be detected in some 
cases). So it is the responsibility of the resource owner to validate 
the authenticity/trustworthiness of an app before using it. The authz 
server's task is to authz access to cloud resources, so it asks the 
resource owner for consent. Once the consent is given, the refresh token 
itself represents the fact that the holder should be a legitimate client.

regards,
Torsten.
------------------------------------------------------------------------
*From: * Dave Rochwerger <[e-mail]>
*Date: *Wed, 14 Sep 2011 13:45:42 -0700
*To: *Torsten Lodderstedt<[e-mail]>
*Cc: *<[e-mail]>
*Subject: *Re: [OAUTH-WG] OAuth2 Implementation questions (client secret 
and refresh tokens)

Is this a security issue in the OAuth2 process then (for mobile apps 
using the authorization code flow)?

1. The draft says that mobile apps should be considered public clients 
because mobile apps can be decompiled and can not keep their credentials 
private.
2. In this case then, the draft says for these mobile apps to not 
authenticate with the secret and instead for the server to verify the 
redirect URI (and make it mandatory).
3. You said that verifying the redirect URI is not good enough to verify 
the client's identity.

What am I missing?

Thanks,
Dave


On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt 
<[e-mail] <mailto:[e-mail]>> wrote:

    Hi Dave,

    redirect URI validation does not authenticate a client. For example,
    a URI registered for a private web client could be used by a
    (malicious) native app to assume the web app's identity. The client
    secret, in contrast, can be used to authenticate it.

    regards,
    Torsten.

    Am 14.09.2011 19:12, schrieb Dave Rochwerger:

        Thanks for the follow up, Torsten.

        Whilst I have your attention - any thoughts on my second question,
        about the use of a client secret?
        If for all clients we mandated registered URIs and verified them
        (whether they are private and public), what additional security does
        the client secret actually provide for private clients in the
        authorization code flow?


        Thanks,
        Dave

        On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt
        <[e-mail] <mailto:[e-mail]>>  wrote:

            Hi Dave,


            On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote:

                1. "The user does not have to be present."
                Maybe I should be more clear. What benefit does that
                have over just a
                long-lived (forever) access token? The cost is the extra
                complication for
                3rd party developers to have to worry about refresh
                tokens. I can not see
                a benefit in our model (everything over SSL, etc) to use
                refresh tokens.
                I want to use refresh tokens - but only if there is a
                reason for them,
                which I can not see at the moment.


            The benefit of refresh tokens significantly depends on your
            access token design. If your access tokens are just a
            pointer to a database you lookup on any API call, the only
            benefit if token rotation (coming back to this topic below).
            But your access tokens could also directly contain all user
            data you need to actually authorize API access. That way you
            could save DB lookups, which scales much better. In this
            model, revocation is much can be easier implement using
            refresh tokens. I think this is what Eran refered to.


                2. "As Eran points out, you'd have to have do a DB
                lookup to have true
                revocation."
                The act of revoking tokens is not a common occurrence,
                DB lookups to
                revoke tokens is not a concern as there is more time
                spent by the user
                navigating the UI (or network latency, etc) than the
                cost of the DB call.

                3. "In this sense you get the best of a long-lived
                credential, combined
                with good key rotation and authorization re-verification
                without having
                to re-involve the end-user."
                That all sounds good, but in our situation (all SSL,
                etc) - what do we
                want key rotation and re-verification for? I fail to see
                a reasonable
                vector for access token leakage to warrant any of this
                in our case.


            rotation is a mean to detect tokem theft from the device
            (see also
            http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2)

            regards,
            Torsten.

                On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote:

                    See below...

                    Phil
                    @independentid
                    www.independentid.com <http://www.independentid.com>
                    [11] [e-mail]
                    <mailto:[e-mail]> [12]


                    On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote:

                        Hi Phil,>>  The client is then forced to
                        periodically reauthenticate
                        (without the user) before getting a new access
                        token.
                        What benefit does that have?

                    The user does not have to be present.

                                Refresh also gives the authzn server a
                                chance to revoke access.

                        Hence it is better to use shorter lived access
                        tokens with long lived
                        refresh tokens.
                        That doesn't follow - we can just as easily
                        revoke the single
                        long-lived access token.

                    As Eran points out, you'd have to have do a DB
                    lookup to have true
                    revocation. But, by having a short expiration time
                    on the access token
                    (say 1 hour or less), you get quasi-revocation which
                    has to be
                    re-validated after the access token expires and the
                    client has to
                    re-authenticate and provide a valid refresh token.
                    In this sense you
                    get the best of a long-lived credential, combined
                    with good key
                    rotation and authorization re-verification without
                    having to re-involve
                    the end-user.

                    Dave.>

                        On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote:

                            You can also use a long lived refresh token
                            in combination with a
                            short access token. The client is then
                            forced to periodically
                            reauthenticate (without the user) before
                            getting a new access
                            token.
                            Refresh also gives the authzn server a
                            chance to revoke access.
                            Hence it is better to use shorter lived
                            access tokens with long
                            lived refresh tokens.

                            Phil

                            On 2011-09-07, at 15:27, William Mills wrote:

                                I'll talk to the refresh token question:
                                they give you a hook for
                                extensibility and key rotation. If you
                                want to rotate your
                                encryption keys or extend the data
                                carried in the token in any
                                way then you want to be able to cleanly
                                refresh your tokens. Note
                                that the refresh flow allows you to
                                issue a new refresh token at
                                the same time. It also allows a clean
                                path to convert tokens in a
                                new client if you decide you want SAML
                                tokens instead of MAC for
                                example.
                                If you want those things you want to use
                                refresh tokens. You can
                                have long lived access tokens too, and
                                just use the refresh
                                tokens when you want to do something new
                                with the access tokens.
                                -bill

                                -------------------------
                                FROM: Dave Rochwerger
                                TO: [e-mail]
                                <mailto:[e-mail]> [2]
                                CC: Quizlet Dev Team
                                SENT: Wednesday, September 7, 2011 2:15 PM
                                SUBJECT: [OAUTH-WG] OAuth2
                                Implementation questions (client

                                secret and refresh tokens)

                                Hi all,
                                I have been implementing OAuth2 based on
                                the various drafts for
                                our new API. Initially, I implemented
                                everything as per the spec,
                                but due to our particular scenario and
                                restrictions we have in
                                place, there are some fundamental
                                questions that I am unable to
                                defend.
                                I am hoping this group could help answer
                                them for me.
                                Our scenario:
                                ==========
                                * We are implementing an API to allow
                                3rd party developers to
                                access users' protected resources via
                                their applications. The
                                applications will mostly be native phone
                                apps, but some will have
                                web server backends (javascript-only
                                applications are not a
                                concern at the moment).
                                * We want to provide very long-lived
                                (forever) tokens.
                                * We are implementing the "authorization
                                code" flow as that seems
                                best suited to us (we don't want the
                                implicit flow because
                                end-users would have to re-authorize
                                every hour).
                                Our architecture:
                                ============
                                * We control both the API server and the
                                authorization server.
                                * All requests to protected resources
                                (ie: to the API server) are
                                always done over SSL.
                                * All requests to the authz server
                                (token and authorize
                                endpoints) are always done over SSL.
                                * We enforce that every client must
                                supply the state parameter
                                (and our guidelines say they must verify
                                the state for CSRF
                                mitigation).
                                * We enforce that every client must
                                register a redirect URI.
                                * We validate the redirect_uri used to
                                request an access token is
                                the same that was used to obtain the
                                auth code.
                                * The only time a request is not made
                                over SSL is the redirect
                                with the auth_code which is very
                                short-lived (30 seconds) and is
                                tied to a verified redirect URI.
                                * We enforce that access tokens must be
                                provided using the
                                Authorization header only (and of
                                course, over SSL).
                                * We have guidelines saying that all
                                mobile apps must use the
                                native browser (and not an embedded web UI).
                                Questions:
                                ========
                                1. Given the above scenario, what use
                                are refresh tokens?
                                - Access tokens can not leak because
                                every request (to resource
                                and authz server) containing an access
                                token is done over SSL. We
                                control both the authz and resource
                                servers, so tokens in logs
                                (and other suggested reasons in the
                                archives) are not an issue.
                                - Long-lived refresh tokens and
                                short-lived access tokens are
                                supposed to provide security due to
                                possible access token
                                leakage... but in our 100% SSL scenario,
                                if access tokens are
                                able to leak, then so would the client
                                id, secret and refresh
                                token.
                                - Having a long-lived refresh token that
                                can be exchanged for
                                another access token adds a level of
                                complexity (a second HTTPS
                                request every so often) and seems to
                                provide no benefit for our
                                case.
                                2. What is the point of the client
                                secret (in our scenario)? -
                                We originally were treating the clients
                                as confidential, but
                                after re-reading the native-application
                                section, it seems we
                                really should treat them as public
                                (phone apps can be decompiled
                                and the secret discovered).

                                - The spec says that the authz server
                                should authenticate
                                confidential clients, but public clients
                                are allowed to just send
                                their public client id (and no secret).
                                - The only verification then, is to
                                enforce redirect URI
                                registration and to validate the
                                redirect URI between
                                authorization and token steps.

                                So, the question is, assuming that we,
                                one: "enforce
                                redirect-URI registration" and two:
                                "validate that URI" - why
                                can't we treat all clients as public and
                                not worry about a
                                secret?
                                What is the benefit of having
                                confidential clients (and a secret)
                                at all?
                                Our API source is not available, but the
                                oauth2 server
                                implementation can be seen here:
                                https://github.com/quizlet/oauth2-php [4]

                                Regards,
                                Dave

                                _______________________________________________
                                OAuth mailing list
                                [e-mail] <mailto:[e-mail]> [5]
                                https://www.ietf.org/mailman/listinfo/oauth
                                [6]


                                _______________________________________________
                                OAuth mailing list
                                [e-mail] <mailto:[e-mail]> [7]
                                https://www.ietf.org/mailman/listinfo/oauth
                                [8]




            Links:
            ------
            [1] mailto:[e-mail] <mailto:[e-mail]>
            [2] mailto:[e-mail] <mailto:[e-mail]>
            [3] mailto:[e-mail] <mailto:[e-mail]>
            [4] https://github.com/quizlet/oauth2-php
            [5] mailto:[e-mail] <mailto:[e-mail]>
            [6] https://www.ietf.org/mailman/listinfo/oauth
            [7] mailto:[e-mail] <mailto:[e-mail]>
            [8] https://www.ietf.org/mailman/listinfo/oauth
            [9] mailto:[e-mail] <mailto:[e-mail]>
            [10] mailto:[e-mail] <mailto:[e-mail]>
            [11] http://www.independentid.com
            [12] mailto:[e-mail] <mailto:[e-mail]>
            [13] mailto:[e-mail] <mailto:[e-mail]>

            _______________________________________________
            OAuth mailing list
            [e-mail] <mailto:[e-mail]>
            https://www.ietf.org/mailman/listinfo/oauth