Username and Password Profile

[Jason Hullinger]

I have a question regarding 5.3 in the OAuth Wrap specification, “Username and Password Profile”. The client makes an HTTPS request to the authorization server’s access token URL using POST with the following parameters:

wrap_client_id - Required. The client identifier
wrap_username - Required. The User’s username
wrap_password - Required. The User’s password
wrap_scope - Optional. Authorization scope values defined by the server
Additional parameters - Any additional parameter defined by the authorization server

From the above parameters there is no way of insuring that a client is ever who they say they are because a user could easily obtain the wrap_client_id and make requests using that. Does anyone have an implementation of this or any recommended additional parameters? This is what I was thinking of possibly using, given that a client’s wrap_client_id and wrap_client_secret are to only be used in this given profile. In other words, if a client wanted to use another authentication profile, they would have to obtain another client id and client secret:

wrap_assertion_format: The hash format
wrap_assertion: A hash of the following: wrap_username + wrap_password + wrap_client_id + wrap_client_secret + timestamp
wrap_timestamp: A valid time stamp within a yet to be determined time frame

A user could always disassemble (or simply read it from a scripting language) a given program and obtain the wrap_client_secret, but if so, it would be no less secure than the required authentication parameters in the specification.

Any recommendations or implementations would be great.

Thanks much,

~/Jason Hullinger

[Marius Scurtescu]

On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger <sshj...@gmail.com> wrote:
> I have a question regarding 5.3 in the OAuth Wrap specification, “Username
> and Password Profile”. The client makes an HTTPS request to the
> authorization server’s access token URL using POST with the following
> parameters:
>
> wrap_client_id - Required. The client identifier
> wrap_username - Required. The User’s username
> wrap_password - Required. The User’s password
> wrap_scope - Optional. Authorization scope values defined by the server
> Additional parameters - Any additional parameter defined by the
> authorization server
>
> From the above parameters there is no way of insuring that a client is ever
> who they say they are because a user could easily obtain the wrap_client_id
> and make requests using that. Does anyone have an implementation of this or
> any recommended additional parameters?

I don't think you need to trust this client itself in any way, the
user trusted the client and provided his/her username and password,
that's all that counts. The should just verify these credentials and
then issue refresh and access tokens.

> This is what I was thinking of
> possibly using, given that a client’s wrap_client_id and wrap_client_secret
> are to only be used in this given profile. In other words, if a client
> wanted to use another authentication profile, they would have to obtain
> another client id and client secret:
>
> wrap_assertion_format: The hash format
> wrap_assertion: A hash of the following: wrap_username + wrap_password +
> wrap_client_id + wrap_client_secret + timestamp
> wrap_timestamp: A valid time stamp within a yet to be determined time frame
>
> A user could always disassemble (or simply read it from a scripting
> language) a given program and obtain the wrap_client_secret, but if so, it
> would be no less secure than the required authentication parameters in the
> specification.

Since clients cannot be trusted, a client secret does not make sense.
In this respect this profile is very similar to the Rich App profile.

Marius

[Luke Shepard]

On Mar 4, 2010, at 3:42 PM, Marius Scurtescu wrote:

> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger <sshj...@gmail.com> wrote:
>>
>> wrap_client_id - Required. The client identifier
>> wrap_username - Required. The User’s username
>> wrap_password - Required. The User’s password
>> wrap_scope - Optional. Authorization scope values defined by the server
>> Additional parameters - Any additional parameter defined by the
>> authorization server
>>
>> From the above parameters there is no way of insuring that a client is ever
>> who they say they are because a user could easily obtain the wrap_client_id
>> and make requests using that. Does anyone have an implementation of this or
>> any recommended additional parameters?
>
> I don't think you need to trust this client itself in any way, the
> user trusted the client and provided his/her username and password,
> that's all that counts. The should just verify these credentials and
> then issue refresh and access tokens.

It's pretty important to Facebook that we be able to validate who the client is when they pass in user credentials. We have pretty strict restrictions on the ability for apps to take user credentials directly and we need to be able to enforce those restrictions. I would like to see the ability to authenticate the app as well in this profile.

[Jason Hullinger]

I don't think you need to trust this client itself in any way, the
user trusted the client and provided his/her username and password,
that's all that counts. The should just verify these credentials and
then issue refresh and access tokens.

A few problems I see in not being able to trust that the client is who they say they are: Certain clients might be given access to post or get data that other clients do not have access to. When using other profiles such as the web profile, if a clients identity has been compromised, a client or provider can reissue a new client secret forcing the client to update their system. Also, if abuse is coming from one particular client, a provider should have the ability to shut down that single client. None of the above though is possible using this profiles means of authentication.

[Dick Hardt]

This profile was motivated by the use case of rich clients where redirection of a browser is challenging. ie. a twitter app on a phone.

Per previous discussions in OAuth, it is not feasible with current platforms for an app running on a user machine to keep secrets from malicious users. A web app of course can keep a secret from the user, but use of this profile by a web app does not seem to make sense.

-- Dick

[David Recordon]

Devices such as an XBox or PS3 can keep secrets which is primarily
where we envision using the username/password profile.

> --
> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
> To post to this group, send email to oauth-...@googlegroups.com.
> To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
>
>

[Dick Hardt]

The spec allows the AS to define additional parameters, so for these specialized use cases, Facebook could ask Microsoft and Sony to include an identifier in the request.

Is that adequate?

[Luke Shepard]

Is Facebook the only one who needs this?

Sent from my iPhone

[Jason Hullinger]

I think there are probably going to be more instances of providers needing this than otherwise. The current Username and Password profile is not a solution in a for every sense, and there clearly is a need for a secure protocol where you can validate that the client is who they say they are in a profile such as on a phone or desktop application.

~/Jason Hullinger

[David Recordon]

+ietf list

[Dick Hardt]

Unlikely. But what you want as an identifier is likely different from anyone else.

Given the nature of xbox and PS3, there are likely not too many others besides Facebook that have this requirement -- but I could easily be mistaken. It happens often. :-)

[Dick Hardt]

On 2010-03-04, at 8:16 PM, Jason Hullinger wrote:

> I think there are probably going to be more instances of providers needing this than otherwise. The current Username and Password profile is not a solution in a for every sense, and there clearly is a need for a secure protocol where you can validate that the client is who they say they are in a profile such as on a phone or desktop application.

As mentioned previously, it is impossible on a desktop app to have trust that the client is who they say they are.

[Dick Hardt]

As was discussed on the OAuth list, desktop apps can NOT be secured, so there is no way to ensure it really is the desktop app you think it is. For most phone platforms, this is also the case. For totally locked platforms where the app is part of the OS (xbox, PS3, some phones, settop boxes) -- then one can have high confidence the app is the app. So far I consider these the exception rather than the rule.

-- Dick

[Jason Hullinger]

If it's impossible to validate who a client is for even one particular protocol in the spec, doesn't this leave a provider's web service open to anyone making an authentication/login request to that implemented profile in the spec? Unless I'm missing something, this is a problem because a provider would be opening themselves up to likely phishing attacks, and no way to stop it except by shutting down the entire protocol that allowed it. Perhaps this is just a documentation issue because implementing this portion of the spec could potentially make a provider less secure with no real way of stopping it after it's implemented.

~/Jason Hullinger

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

[Dick Hardt]

You are correct. If a AS, supports the username and password profile, that means it can be used by any client. Clearly the user has made a trust decision about the client in this case, assuming there really is a user running the client.

One option for a provider to minimize their exposure is they may not issue Access Tokens that have as much power to Clients using the Username and Password profile.

This is a good point to call out in the currently un-written security considerations.

-- Dick

[Allen Tom]

This is why the username/password profile is intended for rich client apps, where invoking a browser is not feasible. Given that the user already downloaded and installed the rich app, popping open a browser is not going to protect the user from a malicious app – for instance, a malicious app could have installed a keylogger before invoking the browser.

Under no circumstances should web applications use the username/password profile. Obviously, a browser is available in this scenario.

However, for rich apps, requiring the app to pop open a browser does protect the user from malicious apps, and that’s why it is OK for these apps to directly ask the user for their password. However, it’s generally much better to invoke a browser – for instance, CAPTCHA and other anti-password cracking defenses and be deployed without having to rewrite clients that are already in the field. Also, some users may need to authenticate with more than just a password – for instance users might have hardware/sms tokens or might need to answer a secret question.

Allen

> To post to this group, send email to  <mailto:oauth-...@googlegroups.com>  <mailto:oauth-...@googlegroups.com>  <mailto:oauth-...@googlegroups.com> oauth-...@googlegroups.com.
> To unsubscribe from this group, send email to  <mailto:oauth-wrap-wg%2Bunsu...@googlegroups.com>  <mailto:oauth-wrap-w...@googlegroups.com>  <mailto:oauth-wrap-w...@googlegroups.com> oauth-wrap-w...@googlegroups.com.
> For more options, visit this group at  <http://groups.google.com/group/oauth-wrap-wg?hl=en>  <http://groups.google.com/group/oauth-wrap-wg?hl=en>  <http://groups.google.com/group/oauth-wrap-wg?hl=en> http://groups.google.com/group/oauth-wrap-wg?hl=en.

>
>

--
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.

To post to this group, send email to  <mailto:oauth-...@googlegroups.com>  <mailto:oauth-...@googlegroups.com>  <mailto:oauth-...@googlegroups.com> oauth-...@googlegroups.com.
To unsubscribe from this group, send email to  <mailto:oauth-wrap-wg%2Bunsu...@googlegroups.com>  <mailto:oauth-wrap-w...@googlegroups.com>  <mailto:oauth-wrap-w...@googlegroups.com> oauth-wrap-w...@googlegroups.com.
For more options, visit this group at  <http://groups.google.com/group/oauth-wrap-wg?hl=en>  <http://groups.google.com/group/oauth-wrap-wg?hl=en>  <http://groups.google.com/group/oauth-wrap-wg?hl=en> http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Allen Tom]

Correction: I meant to say that popping open a browser does NOT protect the user from malicious rich apps. If the user downloaded and installed the malicious app on their system, its too late already.

Allen

On 3/7/10 7:25 PM, "Allen Tom" <at...@yahoo-inc.com> wrote:

[Allen Tom]

Hi Ethan -

In Yahoo's case, we only allow the username/password profile for a very
small number of applications written by Yahoo or by partners under contract,
and only when opening a web browser is not feasible or desirable. We
strongly discourage apps from using this profile, and it's unlikely that
it'll ever be a public interface.

We have a very strong preference that rich client apps invoke a browser
window for the user to authorize the app.

Other Service Providers have similar policies for their equivalent
username/password profile.

Allen

On 3/8/10 6:51 PM, "Ethan Jewett" <esje...@gmail.com> wrote:

> On Sun, Mar 7, 2010 at 10:25 PM, Allen Tom <at...@yahoo-inc.com> wrote:
>> This is why the username/password profile is intended for rich client apps,
>> where invoking a browser is not feasible. Given that the user already
>> downloaded and installed the rich app, popping open a browser is not going
>> to protect the user from a malicious app ­ for instance, a malicious app
>> could have installed a keylogger before invoking the browser.
>

> I disagree. There are a large and growing number of platforms on which
> I can install a rich client application and be confident that it will
> not be able to recover my username and password when I type them into
> my web browser. To name a few that I use every day:
>
> 1. My iPod Touch (non-jail-broken, admittedly)
> 2. Adobe AIR on my Windows XP system
> 3. Mac OS X (users and applications do not run as administrators by default)
>
> On a related note - What stops a provider from implementing the
> username/password pattern on top of normal OAuth or WRAP (thereby
> losing my business ;-)? The token can be pretty much any string of
> text, so the client could embed the username and password into the
> token.
>
> Ethan

[Jason Hullinger]

If one were to obtain the client id of a partner, under the vanilla username/password profile, how would a provider prevent non-partners from connecting to a provider who has implemented this profile?

~/Jason

[David Recordon]

You wouldn't. The profile should include the client secret as well in
the initial request. You could always issue a client a different
secret for use with this profile as well.

--David

> --
> You received this message because you are subscribed to the Google Groups
> "OAuth WRAP WG" group.

> To post to this group, send email to oauth-...@googlegroups.com.

> To unsubscribe from this group, send email to

> oauth-wrap-w...@googlegroups.com.
> For more options, visit this group at

> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>

[Jason Hullinger]

In the Spec (as of 0.9.7.2) for 5.3 (Username and Password profile) it say's to make an HTTPS request using POST with the following parameters:

wrap_client_id (the clients id)
wrap_username (the users username)
wrap_password (the users password)
wrap_scope (optional scope defined by the provider)

Are we talking about the same profile?

~/Jason

[David Recordon]

Yes. I was agreeing with your point and suggesting that the profile
have the client secret added to the request. :)

[Jason Hullinger]

Ah, gotcha, sorry for the misunderstanding. :)

One thing I had thought of to mitigate the risk to the client, or at least allow the client the ability to see what data is going to be sent to the provider as "them" would be this: The user connects as 5.3 specifies, upon success the user is given a token. If the provider and client agree that the user now has authority to act as though all requests are coming from the client, the token is an access token. Otherwise, the client is given the option of being a proxy to all requests. The proxy would be an HTTP post from server to server in which the requested data would include the token the user received and the client's id and password. The client would then have the option of inspecting the data and allowing or denying requests that will be assumed to be made upon the clients behalf.

I realize that this is probably far more complex than desired. If, however, it is agreed that there is no way to assure that the client is ever who they say they are with this profile, at least giving the client the last authority on what is requested on their behalf could be optionally included.

~/Jason

[Luke Shepard]

Can you clarify what you mean by autonomous? Isn't the wrap_username
an end user identity?

Sent from my iPhone

On Mar 9, 2010, at 8:25 AM, "Justin Smith" <just...@microsoft.com>
wrote:

> Part of the motivation behind that profile was to allow an
> autonomous client (no end-user identity passed to the AS) the
> ability to access a web service. In that case, I don't see what the
> client secret (along with the username and password) would be adding.
>
> Ethan - assuming the token is signed by the authorization server,
> how can the client add data to it?

>>>> To post to this group, send email to oauth-wrap-
>>>> w...@googlegroups.com.

>>>> To unsubscribe from this group, send email to
>>>> oauth-wrap-w...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OA...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "OAuth WRAP WG" group.
>> To post to this group, send email to oauth-...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> oauth-wrap-w...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>

[Brian Eaton]

On Mon, Mar 8, 2010 at 10:33 PM, David Recordon <reco...@gmail.com> wrote:
> Yes.  I was agreeing with your point and suggesting that the profile
> have the client secret added to the request. :)

Just so we're clear on use cases... is the primary use case here DRM,
verifying software on client machines?

Or do folks want to use this for server-to-server calls?

I am not an expert on DRM, but if we're going to try to do DRM in WRAP
I think we should
a) learn from prior experience
and
b) get experts involved to write that section of the spec
and
c) call it out as a separate use case and profile, so that people
don't get confused and misuse the spec in dangerous ways.

Cheers,
Brian

[David Recordon]

@Justin, there's a separate client key and secret profile for making
requests not within the context of a given user.

@Brain, I'm not focused on using this profile for DRM. Rather for
trusted devices (ideally with TPM) which do not open web browsers
(such as the XBox).

--David

[Allen Tom]

The problem with using a client secret for trusted devices is that these
secrets usually get extracted over time. For obvious reasons, I'd rather not
get into the details, but there are many examples of devices whose secrets
are not secret.

The motivation for deliberately excluding the client secret from the
username/password profile was to prevent having the illusion that clients
can be authenticated.

I personally have no objection to adding a client secret to the
username/password profile, however, as we've seen with OAuth, doing so will
give the illusion that downloadable apps can be authenticated.

Allen

[Brian Eaton]

On Tue, Mar 9, 2010 at 9:46 AM, David Recordon <reco...@gmail.com> wrote:
> @Brain, I'm not focused on using this profile for DRM.  Rather for
> trusted devices (ideally with TPM) which do not open web browsers
> (such as the XBox).

That sounds a lot like DRM + hardware support. And other folks on
this thread have mentioned platforms with no hardware support.

Note that the proposal to use a client secret is not compatible with a
TPM. To make this work with a TPM you'd need to use public key
cryptography.

Cheers,
Brian

[David Recordon]

I'd rather support the client secret and document the hell out of the
security considerations for the profile.

[Brian Eaton]

On Tue, Mar 9, 2010 at 12:02 PM, David Recordon <reco...@gmail.com> wrote:
> I'd rather support the client secret and document the hell out of the
> security considerations for the profile.

Thinking out loud... what if we called it the "server you trust to use
username and password profile" instead of the client app profile?

That would actually meet the xbox use case, as follows:

1) Microsoft uses magic security sauce to authenticate the xbox to
their servers.
This magic security sauce will be obscure, will probably change
frequently, and is probably going to rely on hardware security
modules. It makes no sense to standardize this, because the goal is
specifically to avoid interoperable implementations. =)

2) Their servers hold the client secret, and use it to authenticate to
whatever service they are using for password validation.
Note that they can actually change this secret, because it is
stored server-side.

I'm sure that people are going to run off and use this profile to
hard-code secrets in their iphone apps, and if the secrets are
important they will be reverse-engineered and abused. But that's what
happens when you take a profile intended for one kind of deployment
environment and use it in a very, very different environment.

(Also note that the user experience/completion rate for the
browser-redirect flows on thick clients can actually be pretty good.
We've done usability studies, and it works:
http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps. For
trusted partners you can customize the login and approval screen as
well.)

Cheers,
Brian

[Allen Tom]

+1

I'd like to keep the existing username/password profile as it currently is,
with the understanding that Service Providers may add additional proprietary
parameters and secret sauce to authenticate the client.

Allen

[Dick Hardt]

+1

[Luke Shepard]

That seems reasonable to me. We should make sure to distill this discussion into a "security considerations" section for that profile.