Re: [OAUTH-WG] Delegation (token) requests

[Ethan Jewett <esjewett at gmail.com>]

Some thoughts on this:

#1 vs. #2

Going with #1 as the standard and #2 as an optional extension makes sense to me.


#3

With regards to #3, I'm skeptical of the existence of common use cases
where it is acceptable for an app to have access to a user's
credentials. I have seen a lot of these bandied about, but they
usually amount to "The app/website is made by a trusted party, so it's
ok for the user to provide his/her password."

I think there are a couple of issues here:

1) Why should the party be trusted if the same thing can be
accomplished without trusting the party with the credentials. Most of
the Twitter account hijackings have been because people have trusted
untrustworthy apps with their credentials. The fact seems to be that
"trusted" = "everybody else is doing it". I don't think we should make
this an option in this case.

2) This argument is often made in the case of official apps for
websites. In this case the argument is incorrect in my opinion. The
app (and by extension the trusted party) does not control the platform
so the app cannot inherit the trust associated with the trusted party.

Are these the use-cases that you had in mind? Am I being too
methodologically pure here?


Security in the transport layer for token exchange:

It seems that in a client that can actually protect the consumer
secret it is a nice bonus to be able to pass tokens in the clear and
dispense with the overhead of SSL/TLS.

For clients that can't protect the consumer secret (any installed
application), then yes, I think it makes a lot of sense to require a
secure connection for the token exchange. Should it also be made
explicit that the consumer secret can be dispensed with in this
situation?

Ethan


On Tue, Oct 6, 2009 at 4:07 PM, Eran Hammer-Lahav <eran at hueniverse.com> wrote:
> There are three well-defined methods for obtaining a token:
>
> 1. Web Delegation (2 steps) - user is redirected to the server, authorizes, redirected back to client with token.
> 2. Web Delegation (3 steps) - client obtains temporary credentials, user authorizes at the server, client exchanges temporary credentials for token.
> 3. Direct Request - client uses the user's username and password to request for a token.
>
> OAuth Core 1.0 supports the #2 option only. There is clear demand for the other two methods.
>
> Many large providers I talked to would like to have #1 to get rid of the temporary credentials (request token). The vast majority of the temporary credentials are never used and waste resources. The 3-steps flow was created to address clients which are unable to receive redirections and therefore have no way to get the token back from the server.
>
> Many developers have asked for #3 for cases where it is perfectly acceptable for an application to have access to the user's credentials, but still provide a single OAuth-based API. This has been also raised in cases where opening a browser is poor or unacceptable user experience.
>
> When making a token request, the client may be required to authenticate itself (using its client credentials). The authentication method is either a shared secret or PK-based.
>
> When sending a token, the server should use a secure channel to ensure the token credentials remain confidential.
>
> When using a shared-secret over a secure channel, there is no reason to sign the request and simply including the secret is enough. If a PK is used, the request has to be signed in some way even over a secure channel (because there is nothing else to send with the request).
>
> Questions:
>
> - Are there use cases where the 3-step flow (#2) is needed?
> - Should we require use of HTTPS for token requests?
> - If it is ok for tokens to be sent unsecure, is it also ok to send client secrets unsecure?
> - How should a PK option work? What should be signed? How should it work over a secure channel?
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>