I have a Silverlight control that's used to author some graphical content, and I am starting work to integrate it to Facebook so people can have access to their pictures. Things are working well, I am using the JavaScript API on the host page of my Silverlight control to interact with Facebook (log in/out, authenticate, etc).
The problem comes when I register my app with Facebook as a web app. This hostpage/Silverlight Control is hosted under several domains. From what I understand, I can register my web app with a domain like www.example.com, and www.example.net, and things will work for similar roots like site.example.com.
But not for www.example2.com. For my application to be able to log in to Facebook under this domain, I would need to register a separate web app with Facebook specifying this second domain, hence having a second Facebook App ID.
Am I understanding correctly? I have a lot of these domains (10+), and will have more in the future. Is there another (better way) to handle this situation?
Related
In web system, when some URL is protected, user is redirected to dedicated auth-page, and after login is (in convenient case) redirected back.
I understand that with mail.google.com and accounts.google.com the reason is huge google infrastructure, and may be different developer groups responsible for accounts and mail. And if I want to make user authenticate using Google, I become a part of it.
But in a average web app I can just do like hasAuth() ? renderProtected() : renderLoginDialog() without any redirects.
Tutorial for react router is showing example with redirects, and materials for server-side frameworks is about to do the same.
Is there any practical benefits (like security) of redirect based solution, or it's just following the trend from the giants?
This is a common implementation of Single sign-on - SSO. You basically sign in once in a dedicated server, and then you can access multiple applications which are not related without signing in again. For example, after sighing in to your google account you can access all google applications (gmail, drive, calendar ...)
My project deals with both Web app and Mobile app. So before we can use Linkedin API's into our project we need to register our app with Linkedin according to this Quick Start. But for my situation where i use Linkedin API's for both web and mobile, Do i need to register two application with Linkedin. Or is there any other way to register a single application and use the same for both web and mobile?
In the registration page i don't see any distinction for Web and Mobile, unlike facebook where a single application registered can be used for both web and mobile app.
If anyone could point me to appropriate docs or pointers, it would be really helpful.
Thank you.
When a user authorizes your LinkedIn Application, their authorization is tied to that particular API key - if you were to use multiple keys in a single user realm, the user would in theory have to authorize both of them.
In short, I don't see any advantage to using multiple keys if your users are going to be exposed to both web and mobile.
I know there is a lot of questions out there already and I've been reading blogs and looking at samples for well over a week and I'm still a little hazy on how some of this is going to work in the real world. The samples are very helpful, some are very complex some are simple, none have really clarified some of my questions.
The system comprises:
Web App (own IIS site, with SSL, consumes Public API)
Public API (own IIS site, with SSL)
Desktop Widget
Mobile (iOS, Android)
3rd Party apps
How best to handle user registration and account creation? Whilst offering OpenID there also needs to be a 'local' login to the web application. Having a method on the API that accepts base data types (strings/dates etc...) values and then creates an account is asking for trouble and a red flag to the spammers. Would it be best to handle this exclusively through the web site employing visual CAPTCHA checks? How does the Facebook mobile app handle this registration scenario?
Lots of samples also seem to use small subsets of the default Forms Authentication database for Membership. They then use Entity Framework and the Membership, WebSecurity or FormsAuthentication, Roles Provider classes in various different ways depending on use case. Are there any alternatives to this approach to consider for the security backend? Our DB guy is considering rolling our own but then we also need to build our own user management app :(
Once a user is registered and logged in to the web app I can't see any way around continuing to authenticate and authorize each call on the WebAPI. I'm assuming at the moment that the API should just implement OAuth and treat the web app as another client app like the mobile app and 3rd party apps.
I think I've read too much without playing with code to settle this in my head. There are so many approaches.
TIA,
I'm trying to figure out, how to use OAuth 2.0 to access Google APIs from my web app. The problem is, that the protocol require developer to register redirect_uri (URL of page receiving access token). But my application can be distributed to many customers and can be hosted on endless number of servers. There is no way to know redirect_uri beforehand.
Google offers another option for installed applications, but I cannot use this variant neither. Auth server returns access code in window title and this information cannot be accessed from javascript of our page (JS cannot access content of window opened using window.open(); if that content comes from different server).
To conclude:
Cannot use method for web applications, because I don't know all URLs where will our app run in the future.
Cannot use method for installed applications, because window title is not accessible from our JavaScript code.
Is there any recommendation, how to use Google's OAuth 2.0 from distributable web application running on a lots of servers? Thank you.
Are you sure you cannot access the window title? If your app is opening the window, it should be able to access it. It should be possible to do this in a similar way you would do it in a mobile app.
If all attempts fail, you could set up a proxy server (that has a known redirect URI) and hands out the Google tokens to all your clients. Or better each of the apps could have its own proxy server - the server it was downloaded from. But then if each OAuth client can only have one redirect URI, each app would have to be a separate OAuth client.
I've recently started working on a game project for mobiles for which I want to maintain user accounts.
Instead of writing my own user accounts layer, I thought I'd allow people to authenticate with Google/Facebook/Twitter etc. accounts. Examining the delegated authentication schemes supported by each of these providers like OAuth/OpenID, it seems like there must be a browser for logging in any of the providers. Can anyone suggest workarounds or straightforward ways to authenticate without having to open a browser.
If that's not possible, how are applications like Google Talk logging in without opening a browser?
The browser is simply speaking HTTP (over TCP). You can create an ASP.NET web service or a WCF web service which also speaks HTTP, which will follow the same sequence of HTTP actions.