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

[Justin Richer]

OK, sounds like the request object is the right path for your use case. 

You can see how MITREid Connect does that processing in this class:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-server/src/main/java/org/mitre/openid/connect/request/ConnectOAuth2RequestFactory.java <https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-server/src/main/java/org/mitre/openid/connect/request/ConnectOAuth2RequestFactory.java>

It’s important to get the precedence of the parameters correct, so be careful about just expanding the map and using that. And checking the signature is obviously required for proper security and functionality. You’re correct about the structure of the request, it’s a JSON Web Signature. I’d suggest using a JOSE/JWT library on your platform to handle the processing of that, if you can. We use (and contribute to) the Nimbus JOSE JWT library on Java, and I can highly recommend it if you’re on Java as well.

As far as the list, reply-all to both poster and list and the server will sort things out.

 — Justin

> On Feb 24, 2015, at 10:05 AM, Lachezar Dobrev <l.dobrev at paladin.bulgarpress.com> wrote:
> 
>  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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150224/8ee70f1c/attachment-0001.htm