insecure request with the new Delegated Authentication
After trying out the sample1 application for Delegated Authentication I get this screen:
"www.contoso.com is making an insecure request to access your information. Windows Live does not allow information to be shared with this type of request." And i can't continue.
the generated url looks like this:
Since i thought it looked a little strnge with the double "app=appid=" I removed "app=", and it works!
well sort of..
back in the Page_load of the delauth-handler some kind of long token string gets passed around in the WindowsLiveLogin class.. and finally returns an empty string! with the error:
Error: DecodeToken: Decryption failed: System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed.
any ideas?
Answers
There are two reasons why you might get this “insecure request” message from the consent server:
1. You passed a bad app verifier
2. You passed a good app verifier, but the return URL you passed is either invalid or doesn’t map to that app verifier
The app= parameter is the app verifier, which explains why removing that parameter sort-of removed the "insecure request" error.
What's probably happening under the covers with your second problem is that the consent server is using the appid secret key you or someone else has previously registered for www.contoso.com to encrypt the token sent back, but your handler can't decode it if it doesn't have the key.
If the consent token starts with delt then it's unencrypted, whereas if it starts with eact then it's encrypted.
When you have registered an appid for delegated auth, you should include the appid and secret key in the app config file and the library code will then use that to generate the correct app verifier for you.
In the URL you posted above, the values of the ru, pl and app parameters of the request aren't URL encoded (the sig parameter of the application verifier is already URL encoded, but this is not enough):
As a consequence, the server receives an incorrect application verifier as the non URL encoded value of the app parameter contains an & (instead of & ). To overcome this problem you have to manually encode the ps, appctx, ru, mkt, pl and app parameters.
If you are using the WindowsLiveLogin class in your application, be sure not to put the return value of the GetConsentUrl function in a Uri class, as it seems to remove the URL encoding from the parameters.
All Replies
There are two reasons why you might get this “insecure request” message from the consent server:
1. You passed a bad app verifier
2. You passed a good app verifier, but the return URL you passed is either invalid or doesn’t map to that app verifier
The app= parameter is the app verifier, which explains why removing that parameter sort-of removed the "insecure request" error.
What's probably happening under the covers with your second problem is that the consent server is using the appid secret key you or someone else has previously registered for www.contoso.com to encrypt the token sent back, but your handler can't decode it if it doesn't have the key.
If the consent token starts with delt then it's unencrypted, whereas if it starts with eact then it's encrypted.
When you have registered an appid for delegated auth, you should include the appid and secret key in the app config file and the library code will then use that to generate the correct app verifier for you.
Both by Appid and Secret is provided in the app settings. The only way i can get it to work now is by setting the "Application verifed required:" to 0 (in the app center) and manually removing everything after "app=appid=" in the query string. I havn't really tried out the cookie returned yet but it passes the ValidateToken function so i guess its alright.
/Thanks for the fast reply
In the URL you posted above, the values of the ru, pl and app parameters of the request aren't URL encoded (the sig parameter of the application verifier is already URL encoded, but this is not enough):
As a consequence, the server receives an incorrect application verifier as the non URL encoded value of the app parameter contains an & (instead of & ). To overcome this problem you have to manually encode the ps, appctx, ru, mkt, pl and app parameters.
If you are using the WindowsLiveLogin class in your application, be sure not to put the return value of the GetConsentUrl function in a Uri class, as it seems to remove the URL encoding from the parameters.
I am trying to integrate WLID into a Silverlight application and I have no choice but to use the UrI class. Is there a way to override this behavior?
