Re: [OAUTH-WG] Call for Adoption

[Brian Campbell <[e-mail]>]

There's at least one smallish deployment that has a different authority for
the Authorization Endpoint and the Token Endpoint.

from https://accounts.google.com/.well-known/openid-configuration :

{
 "issuer": "https://accounts.google.com",
 "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
 "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
 "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo",
 "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 ...
}



On Wed, Jan 27, 2016 at 6:30 AM, John Bradley <[e-mail]> wrote:

> It think requiring a common authority segment for the authorization
> endpoint and the token endpoint might work in common cases, but there are
> legitimate cases where the URI of the Authorization endpoint might be a
> alias in the case of multi tenants, all using a common token endpoint.
>
> The larger problem would be the RS, it is not uncommon to have the AS and
> RS in different domains,  so with bearer tokens unless you make the same
> authority restriction for RS then you are not really stoping the attacker.
>  They can get the AT by impersonating the RS.
>
> I think trying to enforce a common origin policy over OAuth would be a bad
> direction to go.
>
> I understand that it seems like a easy fix on the surface, and it works
> for most of the things people are using OAuth for today, but would be quite
> limiting over the long term.
>
> John B.
> > On Jan 27, 2016, at 7:31 AM, [e-mail] wrote:
> >
> > Hi Hans,
> >
> > Sorry, I mixed up the IdP mix-up attack and the code phishing attack.
> >
> > Mandating the Authorization and Token Endpoint being in the same
> > authority would solve the later without changing the wire protocol.
> >
> > For AS mix-up attack, mandating the client to change the redirection
> endpoint
> > per AS would solve the problem without change the wire protocol.
> >
> > If these are not possible, then we would have to look at changing the
> > wire protocol. The solution that solves the both cases must
> > provide the token endpoint URI authoritatively, which means
> > you have to mandate some variation of discovery mandatory.
> >
> > Nat
> >
> >
> > At 2016-01-27 17:01  Hans Zandbelt wrote:
> >> I don't see how that can deal with the specific form of the attack
> >> where the Client would have sent the authorization request to the
> >> legitimate authorization endpoint of a compromised AS and believes it
> >> gets the response from that, where in fact it was redirected away to
> >> the good AS.
> >> IOW, I don't think this is so much about mixing up endpoints where to
> >> send stuff to, but mixing up the entity/endpoint from which the Client
> >> believes the response was received. That may just be terminology
> >> though.
> >> Bottom line as far as I see is that a wire protocol element in the
> >> response is needed to tell the Client who issued it, regardless of how
> >> the Client deals with configuration of the AS information.
> >> Hans.
> >> On 1/27/16 1:31 AM, Nat Sakimura wrote:
> >>> So, is there a lot of cases that the authority section of the Good AS's
> >>> Authorization Endpoint and the Token Endpoints are different?
> >>> If not, then requiring that they are the same seems to virtually remove
> >>> the attack surface for the mix-up related attacks. It does not
> introduce
> >>> new parameter nor discovery. If it can be done, it probably is not
> worth
> >>> adding a new wire protocol element to mitigate the mix-up variants.
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>