We need to add support to login using windows live into the windows store application. The backend web service authenticates the user identity using one of the well known providers – google, facebook and now windows live.
WebAuthenticationBroker comes handy to get authentication code in the windows store app. authentication code is passed to the backend web service. sample code below:
// redirect_uri parameter is encodeUriCcomponent('https://login.live.com/oauth20_desktop.srf')
// scope can be wl.basic others. refer other scope values here
// client id is created by adding your application here
if (result.responseStatus === Windows.Security.Authentication.Web.WebAuthenticationStatus.success)
var uri = new Windows.Foundation.Uri(result.responseData);
var code = uri.queryParsed.getFirstValueByName('code');
}).then(null, function onerror(innerError)
// handle error
- http://login.live.com/oauth20_token.srf api to get token from authentication code fails with 500 internal server error if HTTP POST is used as per documentation. HTTP GET has to be used instead. documentation is out of date. Refer this thread at msdn.
Recently I am working on authentication and authorization for our backend service. The service will be integrated with some of our store apps. Obvious thing is to enable signup/signin for user using providers like facebook, google, twitter etc. I used oauth 2.0 apis to authenticate with facebook, google and added authorization functionality (to give access token for our apis) in the service.
As part of this effort, was looking at adding twitter support. Twitter oauth api requires consumer key and secret for any request. That means shipping your consumer secret with your app. quick search on net revealed that there were many other folks facing the same issue. thread 1, thread 2, etc.
Summary based on my few hours looking into this is:
1. Twitter does not support oauth 2.0 which support concept of intermediate auth code. When using this flow, way mobile client does not need to put consumer secret key in the client (app) code. Without this, consumer secret needs to be put in the client code. It can be obfuscated but risks associated with leaking your consumer secret, will not be completely mitigated.
2. I do wonder why twitter does not support oauth 2.0 yet?
3. There is likely way out if the whole authentication UI flow is moved to your app server side. client uses webview/browser to walk user through the authentication and authorization flow, starting with a page on your web site; eventually get the access token to the service. related thread
Currently – we will not support twitter sign in, and not try to move the whole signup/signin UI to server side. When the app is ported to say android, will revisit this.
Did you solve similar problem where you had a mobile app with your backend service, wanted to authenticate using well known providers but manage access token for your service apis yourself? Did you keep the signup/signin UI on your web server? Did you use azure ACS service all together to solve it for you?