During a browser based authentication (oauth) some iOS users experience the flow as their Spotify app opening to authenticate rather than in the browser.
When this happens the redirection back to the site uses the default browser rather than the browser that started the flow.
So for example a user may start to authenticate in Chrome or in the Facebook Browser, but is then redirected after authentication to Safari.
If you are maintaining session or states to check against CSRF then this will breaks that.
I also think it would be more consistent for the user to send them back to their original browser.
Related
I tried using passportjs facebook on my website and tested on different browser but there’s a little bit problem when the link is from the facebook app itself specifically on IOS.
Package used: http://www.passportjs.org/packages/passport-facebook/
The scenario is:
Share your login url to post in your facebook timeline
Open facebook app on ipad
Click the link that was posted on facebook timeline to open the login url and a popup browser from facebook app should appear.
Click your facebook login using passportjs
Result:
Session Expired popup appear and you’ll be sign out and ask to login again but not from your url but from the app itself so I’m not getting the response login from it since it is not from passportjs login anymore. Any idea how to solve this or why is this happening?
So after some trial & error reading I found out I just need to turn on the "Force Web OAuth Reauthentication" inside Facebook Developer dashboard and now it continue login from IOS Facebook app when the link is from their.
I have POC Xamarin Forms PCL app and authenticated successfully with MSAL. My REST calls(to read user profile and sharepoint list data) to graph API are all successful.
I am trying to open a sharepoint page in the browser using the token, i.e. without asking the users the re-authenticate.
Device.openUri always sends the users to an auth page, which makes sense since i am not sending the token with it.
Is this possible at all? If so, How can it be done?
The short answer to exactly what you're asking is "no", and to what you are looking to achieve is "probably not". At least not today with MSAL directly.
When the user is sent off to sign in, MSAL is invoking a platform-dependent browser window which navigates to Azure AD for the sign-in and consent process. Depending on the device platform, this browser window may (or may not) share a cookie state with other apps and the full browser.
If it does share the cookie space, then the cookies set during the sign-in to your app can be re-used when you launch SharePoint in the browser, to provide a relatively seamless sign-in straight to SharePoint. If it does not, then there will be no existing browser session artifacts (i.e. cookies) that Azure AD can use to provide single sign-in.
For example, on iOS (Xamarin), MSAL for .NET will invoke SFSafariViewController. SFSafariViewController does not share cookie space with other apps or with the Safari browser.
I have creating a website running on Node.js and Express. For logging into my website I use passport.js based social login with Google, Facebook and Live.
I need to expose user data via authenticated REST services so that website's Chrome & Firefox browser extension can do CRUD operations.
When user clicks on a button injected via browser extension, I need to check if user is already logged in to website. If user is not logged in then I will do a redirect for login and return back to original page.
I am clueless after this. Which token do I use for REST API calls ?
Any Advice ?
After the social login, when the user is redirected to the callback url, you can create your own token, e.g. using uuid, and then send it to the client.
For all the consequent requests the client needs to use that token for authentication and you have to manage its expiration.
I built an AngularJS application calling some REST API's belonging to my own backend (using Play! 2.2).
I'm using Facebook OAuth client in order to authenticate my users.
As being a Javascript App, my Facebook App Token cannot be "hidden".
Thus, anybody who picked up the Facebook App Token, by just reading the Javascript code could grab a user access token in a "legally" way and therefore use my REST API's.
How could I prevent it?
What is the best practice?
One way would be, I think, to use the server side Facebook's OAuth mechanism, rather than the Facebook Javascript SDK.
In this case, the Facebook app secret would be stored on my server and unreachable from the outside.
But as being a Single Page Application on client-side, I really want to avoid page redirection and benefit of the "popup" feature that comes with Facebook Javascript SDK.
There are a couple of things you can do.
Using the server side ("code") OAuth flow for facebook auth is much more secure. You can still avoid redirects by opening your own popup to initiate the login sequence, similar to what the Facebook JS does (only it goes to your server first).
Enabling HTTPS on your application is usually a good practice...
And if you're worried about cross site forgeries you can implement something like an anti forgery state token. See http://blog.codinghorror.com/preventing-csrf-and-xsrf-attacks/ and also google's instructions here https://developers.google.com/accounts/docs/OAuth2Login#createxsrftoken .
I am building a cross platform mobile application (using the Xamarian tools, MonoTouch / MonoDroid). I am trying to work through the authentication workflow and am running into a stumbling block. I have searched all over for a clear answer and have yet to find it.
Here is an overview of my current setup.
I have a web site built in nodejs.
I use passport.js to do oAuth login on the web site. This works great, users can login to my site using Twitter or Facebook.
Now I want to extend this same login functionality to my mobile clients.
I see 2 options
Embed the app id and app secret's in the mobile clients and make direct oAuth calls to FB or Twitter from the mobile app
Proxy the oAuth calls through my existing nodejs web server (keeping the secret keys on the server)
Option 2 appears to be the preferred way (as it avoids having to "ship" the secret in the mobile apps).
I have the proxy approach mostly working.
I open a WebView in my mobile client and point it at http://mysever/auth/twitter
This runs through my existing passport.js code and redirects the mobile WebView over to the Twitter login page.
The user then enters their creds on the twitter webpage on the device.
Twitter then calls my oAuth callback URL (which is my nodejs web server).
My server and Twitter handle the back a fourth handshake of obtaining the user profile information (As I understand it, this is the key to this approach, my server and twitter handle the handshake, the mobile client doesn't have to do anything or pass any tokens during this process)
Here is my problem:
It is this last step that stumps me. Once the handshake is complete on my server I have the user information I need on the server and need to send it back to the mobile client application
I can't figure out any way in the WebView control to grab the response object and grab a cookie, or header value (for instance) (this seems true for Android and iOS). I don't think it is platform specific. I think I am trying to do something that a WebView widget in mobile platforms just don't suport. It makes me think I am missing something obvious.
The only thing I have figured out is to have my web server "redirect" the mobile client browser to a fake URL that has the user info in the querystring. Something like myapp://info?userid=1234
Then in the mobile app I can hijack the URL loading and grab this url and get the data I need. I can then stash this userinfo, close the WebView control and move on to a native screen in my mobile application and user the userinfo in any subsequent REST calls to my nodejs server as a means of identifying the user.
This is massively kludgy for multiple reasons. The biggest of which is that the url is sent over the wire unencrypted and has all the data in plain text.
There has to be a better way to get the data from the web server back to the mobile client?
Or am I doing it all wrong?
The most straightforward way to implement oauth for Xamarin, both for iOS and Android, is using Xamarin.Auth. The starter documentation for the client is here. I think it should maintain everything securely and you will not have to worry about having to use your node server as a proxy.
You will need to provide your Application ID as part of the calls, but I don't there are too many or any security issues to worry about there.
I know this is going against what you already have implemented, but maybe this could help simplify things a bit.
This is the same dilemma that I have been dealing with.
This is how I currently deal with it.
In my app the client can come directly or via another service such as facebook which is my main one and hence the one which I have concentrated on.
Facebook can either redirect via a POST (desk apps) or a GET (mobile).
I check the initial request so see if has a service identifier - here is the facebook GET for example.
app.get('/', function(req, res) {
var paraUrl = URL.parse(req.url,true).query;
//The fb_source is shown -
//i need to go striaght to the facebook authorization since
//its coming from
//from a mobile device.
if (paraUrl.fb_source){
res.redirect('/auth/facebook'); //this is the passport part
return;
}
res.sendfile('index.html');
}
The facebook POST is slightly different in that you get an access token encode in base64url. The GET gives you a code which you can exchange for an access token but I had problems with it and just opted for tying into the passport system.
If a client comes direct I check for the session or a encrypted cookie which ties into the local strategy. This then checks the db for an access token which can used to access the facebook api for example.
If a client is unrecognised they are given the option to authenticate via facebook, google etc.
The main thing is that only 2 pieces of information are stored with the client, the passport session id and my app user id
connect.sid - encypted cookie
userId - encypted cookie
I would be interested to find out how other people are dealing with issue