By convincing the client to use a bad URL. That’s kinda why we’re worried about bad discovery no?
Depending on the type of client authentication, the client will establish a valid connection to the hacker’s proxy which then replays the token request to the real endpoint. The hacker now has the token. Same thing for the resource endpoint - except worse. The hacker doesn’t need the token as they now see the payload. Phil @independentid www.independentid.com <http://www.independentid.com/>[email protected] <mailto:[email protected]> > On Mar 18, 2016, at 3:38 PM, Brian Campbell <[email protected]> > wrote: > > How does one Mitm the token endpoint? > > On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
