How does one Mitm the token endpoint? On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote:
> 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
