Subject: [OAUTH-WG] End user auth response code-and-token's scope parameter

From: Andrew Arnott <[email-masked]>
Date: Fri, 2 Jul 2010 09:26:02 -0700

> If the response type is code-and-token, the authorization server adds the
> codeand state parameters to the redirection URI query component and the
> access_token, scope, and expires_in to the redirection URI fragment using
> theapplication/x-www-form-urlencoded format as defined by...

Since the scope applies equally to both the code and access_token
parameters, it seems that scope should be included in the URI query part so
it is available to the web server as well as the user-agent.  While the
scope remains in the fragment, the client's web server won't know whether
the full scope it requested was actually granted.

Was there an advantage to including the scope only in the #fragment, or was
this just an oversight?

Thanks.

--
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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Jul 2010 09:31:10 -0700

Scope is specific to the access token, not the code. In fact, I expect some providers to issue an access token with a lesser scope than that provided when exchanging the authorization code later (which will include another scope). This is because the authorization server can authenticate the client when using the authorization code and provide greater access.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Arnott
Sent: Friday, July 02, 2010 9:26 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] End user auth response code-and-token's scope parameter

If the response type is code-and-token, the authorization server adds the codeand state parameters to the redirection URI query component and theaccess_token, scope, and expires_in to the redirection URI fragment using theapplication/x-www-form-urlencoded format as defined by...

Since the scope applies equally to both the code and access_token parameters, it seems that scope should be included in the URI query part so it is available to the web server as well as the user-agent.  While the scope remains in the fragment, the client's web server won't know whether the full scope it requested was actually granted.

Was there an advantage to including the scope only in the #fragment, or was this just an oversight?

Thanks.

--
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

---

From: Andrew Arnott <[email-masked]>
Date: Fri, 2 Jul 2010 09:51:22 -0700

Ah!  Yes I'd missed the second scope parameter that web servers have the
opportunity to see.  And your point makes sense.

Is this reduced scope on the access token, and the encouragement for a
registered redirect_uri, the only mitigations we have for this possible
attack?

Popular client app *A *is broadly authorized by users on the web.  Evil
client app *B* is added as javascript on a web site.  Victim visits that web
site, and the evil client quietly requests an access token from auth server
using a request claiming to be from client app *A*.  Since client app
*A* wasn't
required to register a redirect_uri and did not do so, client app *B* is
successful in supplying its own redirect_uri and gains an access token
without user intervention or knowledge, since the user had already
authorized client A and the auth server just freely granted a new access
token.  Client app B then uses AJAX to send access token to the attacker,
who can now exploit the access token from a separate machine.

I brought this attack up once before.  I really feel the spec should forbid
issuing access tokens directly to user-agent clients when they haven't
registered a redirect_uri.  Another mitigation is that implicit re-issuing
of an access token to a previously authorized client should be banned
without a registered redirect_uri (although this only reduces the risk, as
the user is still presented with the wrong client name).

Thoughts?

On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> Scope is specific to the access token, not the code. In fact, I expect some
> providers to issue an access token with a lesser scope than that provided
> when exchanging the authorization code later (which will include another
> scope). This is because the authorization server can authenticate the client
> when using the authorization code and provide greater access.
>
>
>
> EHL
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Andrew Arnott
> *Sent:* Friday, July 02, 2010 9:26 AM
> *To:* OAuth WG ([email-masked])
> *Subject:* [OAUTH-WG] End user auth response code-and-token's scope
> parameter
>
>
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Jul 2010 10:02:26 -0700

At the end of the day, there isn't much you can do about user-agent clients. Even a registered redirection URI doesn't really help because that endpoint too cannot authenticate the client.

EHL

From: Andrew Arnott [mailto:[email-masked]]
Sent: Friday, July 02, 2010 9:51 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope parameter

Ah!  Yes I'd missed the second scope parameter that web servers have the opportunity to see.  And your point makes sense.

Is this reduced scope on the access token, and the encouragement for a registered redirect_uri, the only mitigations we have for this possible attack?

Popular client app A is broadly authorized by users on the web.  Evil client app B is added as javascript on a web site.  Victim visits that web site, and the evil client quietly requests an access token from auth server using a request claiming to be from client app A.  Since client app A wasn't required to register a redirect_uri and did not do so, client app B is successful in supplying its own redirect_uri and gains an access token without user intervention or knowledge, since the user had already authorized client A and the auth server just freely granted a new access token.  Client app B then uses AJAX to send access token to the attacker, who can now exploit the access token from a separate machine.

I brought this attack up once before.  I really feel the spec should forbid issuing access tokens directly to user-agent clients when they haven't registered a redirect_uri.  Another mitigation is that implicit re-issuing of an access token to a previously authorized client should be banned without a registered redirect_uri (although this only reduces the risk, as the user is still presented with the wrong client name).

Thoughts?

On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Scope is specific to the access token, not the code. In fact, I expect some providers to issue an access token with a lesser scope than that provided when exchanging the authorization code later (which will include another scope). This is because the authorization server can authenticate the client when using the authorization code and provide greater access.

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew Arnott
Sent: Friday, July 02, 2010 9:26 AM
To: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: [OAUTH-WG] End user auth response code-and-token's scope parameter

Thanks.