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 <[email protected]> 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, [email protected] 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
