On Jul 15, 2010, at 1:10 PM, Torsten Lodderstedt wrote: > Why don't you use the client secret to authenticate the application? The spec > allows you to use a BASIC authorization header for that purpose. We hadn't thought of that, but suits perfectly to our use case! Thanks! > > Regards, > Torsten. > > > Am 15.07.2010 um 12:54 schrieb Elena Lozano <[email protected]>: > >> Hi everyone, >> >> As we adapt the RedIRIS PHP OAuth2 library[1] to the last version of the >> draft we have found some issues regarding the client secret and client id. >> >> The thing is that we don't understand the security given with the client_id >> and client_secret of the assertion profile. >> >> The last changes on the protocol said that: >> >> "the authorization server MUST verify that the >> redirection URI received matches the registered URI associated with >> the client identifier." >> >> This provides one way to perform the correct identification of the client >> but doesn't work with the assertion profile. >> >> In the assertion profile, we understand that the client_id is optional and >> that the assertion could have the information about the client >> identification. >> This could happen when the assertion authorizes an application, but in our >> use cases, the assertions doesn't have information about the client >> application. >> This is a problem because in our request to the Auth Server we cannot check >> if the application is registered correctly. We can send the client_id in the >> request, but we have the same problem, because someone can 'steal' our >> client id and impersonate the client. >> >> We think that we can solve that signing parameters in the request, adding >> the client_id signature or something like this but we're not sure that this >> is referred in the protocol. >> >> What do you think it's better to solve this issue? >> >> I don't know if i'm understanding something in a wrong way, so please >> correct me if i'm wrong. >> >> Thanks! >> >> Elena. >> >> [1] http://www.rediris.es/oauth2 >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
