I am working on designing an api/application structure to mimick facebook's for a project of mine. I am wondering what the best way of going about authenticating users is.
For an app how do I give them the nessecaru credentials and how do I authenticate those credentials?
I would investigate these technologies before I started down the road:
OpenSocial this is basically the "open source" facebook platform. You can set up your site as a container, or an application (or some funky combo of both).
OpenID if you just want to be able to authenticate people using their login credentials from another trusted site
OAuth if your looking for a API style authentication framework
All of these techs have reference implementations in the usual suspects and are supposed to be more "open" than anything facebook is doing. We will see what happens in the long run...
Well the facebook api actually has an open source implementation so that's fine. But I'm wondering how does facebook actually authenticate everything? Like how do they pass user data to you?
Related
I'm having trouble understanding how ASP.NET Core authentication works.
I want to implement JWT access token authentication with refresh tokens. To my knowledge, this is the industry standard for authenticating a client (Mobile app, SPA Web application). For security purposes, I'd prefer to not implement my own authorization logic including JWT generation and refresh token handling. Since ASP.Net does not natively support this, Naturally my choice would be to use IdentityServer4, a large open source library for handling this kind of stuff.
However IdentityServer4 is heavily based on OAuth, and I'm not sure how that works with SPA applications and mobile apps (clients I trust). It requires the client to redirect to some arbitrary webpage to enter their credentials and then redirect back to the app. Gross. I've never seen a major app like Snapchat, Instagram, etc. have this kind of authentication flow where you are directed to some webpage/browser during the login flow. Luckily IdentityServer4 has a little feature to handle username/password authentication for my trusted clients (http://docs.identityserver.io/en/latest/quickstarts/2_resource_owner_passwords.html)
Great, that seems to suit my needs. But... Now I want to add Facebook Authentication. IdentityServer4 allows for External Authentication, however it is still cookie based (to my knowledge). Which requires the Android/iOS/SPA app to redirect to a webpage and then redirect back to the app. Again, this isn't ideal from a user perspective. Facebook provides native mobile SDKs to handle this type of authentication which returns an access token so there is no need to redirect to web pages using cookies.
Now lets say my iOS app uses the Facebook SDK to grab an access token for the user and sends it to the backend. The backend validates the token against the Facebook SDK, and subsequently registers a local user in it's own database.
Now when that same iOS user tries to login to the app, the app will generate a facebook access token for that user from the SDK and send it to the backend. However I'm not sure how to utilize IdentityServer4 to generate a JWT for the user since I need that users' username and password. This is where I'm stuck. I seem to be fighting against the library which makes me believe I am severely misunderstanding something.
TLDR; IdentityServer4 seems to be heavily based on cookies which doesn't really fit nicely into mobile apps/SPA webpages when you are redirected back and forth from authentication webpages. Am I using the wrong tool for the job? What are some alternative solutions?
As a note on big social apps: I think it comes down to who keeps the passwords. Facebook, Instagram, Snapchat, Google act as identity providers to third parties. They themselves require user to register and specify the password which they keep. Therefore they can use any customized approach for handling validation with those passwords. However, if any of them offerred a posibiltty to log-in with the other I.e Instagram were allowing to sign-in with Amazon credentials, then they would need to follow through a standard way like OAuth and redirect to the third party for log-in. Last time I checked Instagram, Facebook and Snapchat only offer to register and no option to sign in with 3rd parties which explains why the don't need redirects.
Now if we establish that a redirect is a necessary evil, then the means to carry over the data accross aren't that numerous. I.e. we either would need to pass data via a query string or use cookies. Am I missing any others?
Both have limitations but since cookies are persisted and browser carries them automatically with each request, they do seem like a better option for the job, especially if multiple redirects are required for an external IdP to track the state of authentication request. The same reason is mentioned here:
http://docs.identityserver.io/en/latest/topics/signin_external_providers.html
It's absolutely the right tool for the job if you want what OpenID Connect and OAuth2 give you. It sounds like you may need convincing though and it may be that your use case doesn't need the full breadth of functionality offered.
If you have multiple client applications and APIs in play then I think using OpenID Connect and IdentityServer4 the right choice at this point in time.
Regarding native apps, you used to word "gross" to describe using the user's default browser to perform the sign in process and it's understandable why you might think that at first but it's not as bad of a UX as you'd think and has plenty of advantages:
The client application is completely decoupled from how authentication is actually done be that federation, social sign in (Facebook in your case), multi-factor, retina scan etc. Your identity server deals with all that complexity and is a single point of management (and failure - so make it highly available!)
Single sign on is possible - if they're already signed into your IDP then they can go straight in (although you have full control of the flow - want them to consent or confirm the sign in request every time - you can do that)
If the user has a password manager set up in their browser then that'll work too
Both iOS and Android offer APIs for doing this stuff and the work well. If you skin your native and web UIs to look similar the flow from a user's PoV is not jarring at all.
You can still use refresh tokens (ultimately secured by the platform) so you don't actually have to do the interactive flow very often anyway.
Some additional reading below. Quite a lot of thinking has gone into this from the industry so it's definitely worth digesting the current best practice.
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
IETF current best practice: https://www.rfc-editor.org/rfc/rfc8252
Don't make Scott hate you ;) : https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications
For client side SPA browser apps OIDC provides the implicit grant type and uses a silent refresh and IDP session monitoring mechanism to maintain the session. Check out the oidc-client-js library which implements this approach.
I know the accounts-facebook package is very usefull when one wants users to sign in with their Facebook credentials, but is this also possible using Facebook Workplace accounts? I can't seem to find anything helpful on this subject and was wondering if anyone has run into this puzzle before..
Per this earlier question, Facebook Workplace doesn't expose an API for authenticating users, so it would not be possible to authenticate with it directly.
Facebook Workplace does, however, have support for several SSO Providers. Most of these services have an AD bindings, which are supported by Meteor, so you could easily switch to using one of these services, and connect both Facebook Workplace and your Meteor app to that.
I've been having some problems trying to understand the Oauth requirements for Server-side applications which don't require User interaction when querying google API's.
Apologies if this seems obvious to most, but the issue I have is that all the examples and Oauth flows are based on prompting a user to either authorize which features the application has access to or authenticate the user with a google account before being granted a token and refresh token.
Does anyone have experience querying the Sheets API from a server side app without user interaction that could give me some pointers on how to create the Auth token?
I'll be using Javascript, AJAX and JSON to call the REST API.
Many thanks,
Billy
Thanks pinoyyid, having searched this site for and hour and playing around with Oauth playground for better part of an hour, it's frustrating to know the answer was right under my nose in the settings!
Thanks again, really appreciate you pointing me to How do I authorise an app (web or installed) without user intervention? (canonical ?).
For those reading this in the future the link in the comment above will solve your problem, to summarise, you can use your own app settings by going to the google Oauth playground and on the top right select the settings (picture of a cog/gear) and ticking the box to use your app details, enter the client ID and client secret, job done.
Cheers,
Billy
I am trying to develop a non-web application (mobile, non-mobile) for consuming information from Foursquare.
I would like to have the user authenticated by entering a valid username and password and accessing his account using this authentication.
Is this possible? From what I've read, it seems the only way to access Foursquare is by using OAuth, which is not what I had in mind.
Any thoughts?
Thanks!
RP
OAuth isn't a protocol that works only with webbrowsers. However, many OAuth services provide a web-only authorization endpoint. Once the authorization part is done, you can use OAuth from any application, web, desktop or mobile (and embedded systems).
There are many ways to handle this browser requirement, but these two are very common:
Simply embed a webbrowser in your application that shows the user the authorization page, let him log in, and finish the OAuth sequence. Once that's done, you have the keys and don't need the browser anymore.
Use an external browser. This is definitely the recommended approach, since it's more secure and users will probably like it a little bit more. The idea is that you simply open the authorization URL using the user's webbrowser, and set a redirect URL that points back at the app. This is normally done using a myapp://auth URL, which will simply send the data to the application again.
I believe OAuth is your only option if you plan on using the Foursquare api. You can read about Foursquare's Authorization here https://developer.foursquare.com/overview/auth
I recently was tasked to implement Single Sign In functionality where users could register and sign in to this site using their credentials from a more popular site. That got me to start looking and asking around as to who was doing Single Sign In. I was surprised to learn how much of a hot button topic it turned out to be.
If you have rolled out Single Sign In for a web application, then which authentication providers did you end up using and why?
Try OpenID, stackoverflow uses it as well.
OpenID is very good if its an internet application. Lets users use things like their google account to log into yours.
If it is an intranet application then Windows Auth is fairly common but it works best with IE.