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

Mike Jones Michael.Jones at microsoft.com
Fri Oct 30 20:14:56 UTC 2015


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<mailto:Sascha.Preibisch at ca.com>
Sent: ‎10/‎30/‎2015 1:00 PM
To: openid-specs-ab at lists.openid.net<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20151030/92512a19/attachment.html>


More information about the Openid-specs-ab mailing list