There are two variations. Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's. Phil > On Mar 18, 2016, at 15:04, Brian Campbell <bcampb...@pingidentity.com> wrote: > > The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated > by returning an identifier for the AS in the authorization response. It is > something that needs to be addressed but "discovery" or metadata aren't > needed and audience restricted access tokens tokens don't help. > > Maybe that's obvious but there seems to be a lot of confusion on all this so > I wanted to reiterate it. > >> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher <gffle...@aol.com> wrote: >> Goals: >> >> 1. Help the client not send a token to the "wrong" endpoint >> a. wrong AS /token endpoint >> b. evil RS endpoint(s) >> 2. Allow good RS to determine if the token being validated was intended for >> that RS >> >> Other high-level goals? >> >> Use cases: >> >> 1. RS that supports multiple AS (we've had this in production since 2011) >> 2. RS rejects token not issued for use at the RS >> 3. Client that dynamically supports new RS (say any client that supports the >> jabber API) >> 4. Client that dynamically supports new AS >> >> Feel free to add to the list :) >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
