[mitreid-connect] Authenticating the Consumer for the authorisation?

[Lachezar Dobrev]

  The part that costs money is the communication with the user for
authorization. I can not see how to postpone that, so that it comes into
play after the token has been issued.

  After I asked I took a deeper look and found about the request object.
Looking further I found out, that I needed to use the
signedAuthRequestUrlBuilder instead of the plainAuthRequestUrlBuilder in
the simple-web-app.

  As far as I can see when a Consumer registers itself with the Provider
it supplies JWK location for the Consumer's keys. Are these the keys
that the Consumer signs requests with?
  As this is not a free-for-all service I am OK with explicit
registration for the Consumers, including the public key with which they
will sign the requests.

  If I understand correctly with the request object the three parts will be:
   <json header object containing signature algorithm>
  .
   <json request object containing same key:value pairs as a request>
  .
   <Web-Safe-URL encoded signature byte array>

  Am I wrong?

  My current implementation handles (except for the actual signature
checking) the request object by expanding the middle part and simulating
a Request Parameter Map.

  Thanks again for the time spent to help.

  P.S. What is this mailing list's preference for responding: respond to
list only, or respond to list and sender? Because the mails do not have
a Reply-To header set. Is the list smart enough to not forward the mails
to explicit recipients?

На 24.02.2015 в 15:59, Justin Richer написа:
> At the Authorization endpoint, there’s nothing in core OAuth that will
> authenticate the client. The authentication comes on the back end when the
> token is issued in response to the auth code (in the auth code flow at least).
> So the easy solution is to have the part that costs money come into play in
> the back end, when the token is created and the client is authenticated, if
> you can manage that. If not, you do have some other options.
> 
> With OpenID Connect, you do have a mechanism for authenticating the
> authorization request: the request object. Assuming your server supports
> request objects, and your client can generate and sign them, which the
> server and client of MITREid Connect both do. You need to register your
> public key with the server and use your private key to sign the request
> object, or use your client secret to symmetrically sign the request object.
> Either way you likely need to register your client’s request object signing
> algorithm with the server. You can configure the MITREid Connect client to
> send signed request objects by using the SignedAuthorizationRequest
> component, detailed here:
> 
> https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/wiki/Client-configuration#signed-authorization-request
> 
>   — Justin
> 
>> On Feb 24, 2015, at 6:09 AM, Lachezar Dobrev <l.dobrev at paladin.bulgarpress.com> wrote:
>>
>>  Hey all.
>>
>>  I am developing an OpenID-Connect provider.
>>  After some serious head-banging I've succeeded in making a provider
>> that the MitreID-Connect simple-web-app can authenticate/authorise via.
>>
>>  Now the problem I'm facing is authenticating the authorisation
>> requests. The implementation has an authorisation procedure that costs
>> money. However the authorisation request only contains a client_id that
>> can be (relatively) easily duplicated and used to perform authorisation
>> requests on behalf of a real client.
>>  If I understand correctly the authentication/authorisation process
>> begins with the Client forwarding the User for the Provider, hence no
>> Headers can be sent with the Authorisation request.
>>  What options do I have to authenticate the Client?