[Openid-specs-ab] Securing token requests when discovery service is used

Thomas Broyer t.broyer at gmail.com
Mon Nov 2 11:09:28 UTC 2015

Correct me if I'm wrong but couldn't *all* endpoints be man-in-the-middled?

First, using a discovery document where only the token endpoint is changed
(as suggested in the OP, and in [1]), clients could possibly detect the
"attack" by comparing the endpoints domain names, or even DNS registration
infos and/or TLS certificate infos.
The attacker could/would then change all endpoints to proxy them all, and
in this case the attack is "visible" if you look at the requests made by
the user's browser, but in practice "invisible" as the malicious
authorization endpoint would transparently redirect to the "honest" one.
Sending any kind of "secret" or "constant value" wouldn't change anything
then, as the attacker could transparently replace it (as it'd intercept all
And the keys of the client aren't of much help either as the attacker could
also proxy the registration endpoint.
All of this would make the attacker more "visible", but who would notice it
in practice? (or more accurately: it could intercept many requests –and
grab private information and/or do harm– before being detected).


On Mon, Nov 2, 2015 at 3:26 AM John Bradley <ve7jtb at ve7jtb.com> wrote:

> The attack is not on the authentication, it is on intercepting the code
> and being able to replay it.
> Using a key the client is given from  registration to authenticate the
> request to the token endpoint won’t help because that can just be man in
> the middled by the attacker as well.
> This is also not specific to dynamic client registration.  It just makes
> it easier.  I could make the client come to a site to register and give it
> bad endpoints as well.
> In Connect if you do a id_token code flow the issuer in the returned token
> would be wrong for the request so that should actually stop the attack on a
> client that is validating id_token correctly in that flow.  (allowing late
> binding per one proposal will make this vulnerable as well I think.
> In the code only flow it is much harder to stop because the attacker can
> register itself and then replay any keys it gets from the real AS.
> If the client provides a public key in registration that would help if we
> used signed requests.
> To stop the attack you really need to send the token endpoint URI in the
> request to the Authorization server, or use a asymmetric pkce challenge
> verifier.
> I haven’t had a chance to organize the options yet.
> John B.
> On Oct 31, 2015, at 5:14 AM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
> The other thing that can't be faked by an attacker is the OP's keys. If
> the ID token isn't signed by the right keys, then the RP knows that there's
> a problem.  This points to a possible solution involving authenticating the
> jwks_uri value.
> Remember also that the Implicit flows don't use a token endpoint. So
> solutions that involve authenticating the token endpoint won't work for
> deployments using only Implicit flows.
> John, Justin, and Nov, when you send in your IIW session notes, can you
> also please send them here?
> Thanks,
> -- Mike
> ------------------------------
> From: Preibisch, Sascha H <Sascha.Preibisch at ca.com>
> Sent: ‎10/‎30/‎2015 1:00 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Securing token requests when discovery service
> is used
> Hi!
> Now that IIW is over I would like to bring up my thoughts regarding the
> session we had with John regarding the discovery service issue.
> If I am the 'bad' discovery service provider I can fake all values within
> the discovery response. Except for the /token endpoint. That has to point
> to my system in order for me to receive the authorization_code and client
> credentials.
> Therefore I believe there are two solutions:
> * the discovery response to the client has to include a secret which has
> to be included
> in the initial /authorize request. The authorization server validates the
> value and fails the request if it is invalid. This of course has the
> drawback that the authorization server has to keep state. As a server guy
> I would not like to support this flow
> * The better solution I see, and as I mentioned during the discussion, is
> that the client should include the target /token endpoint as an additional
> request parameter for the initial /authorize request. The authorization
> server does a simple string comparison and fails if the /token endpoint is
> not the one as expected
> Regards,
> Sascha
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20151102/065ee294/attachment.html>

More information about the Openid-specs-ab mailing list