I'm creating my own social network and I've made an authentification server in JavaScript, with Json Web Tokens. Now, I want to integrate the Snapchat Login Kitto my app but it gives a token and it makes what I have made.
So that is my question : how can I use the Snapchat Login Kit to create a real account with my API and to allow the user to login with this?
Thanks
I would recommend server tools like firebase, Parse, Back4app, and many others that have the ability to create a user with multiple platforms with like Google, Facebook and many others. Personally, it might be best if you don't use snapchat because of the fact that a lot of people don't have snapchat and their credentials are hard to remember when you are not having to log into the app for a long time so the user might be asked to put in their password that they do not remember.
Related
I am working with a research group that needs to collect Facebook post data for a group of participants over the course of a few months. The goal is let the participants authorize us to collect this information via facebook, and when they post to Facebook, send that information to a secured server.
After reading the Facebook documentation, I'm mostly just confused about how to provide a mechanism for the user to agree to the terms of collecting his/her data. I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
You most likely won't get this approved in review anyway.
Permissions must, for the most part, be used to provide a direct benefit to the in-app user experience; collecting data for analytical measures only is explicitly mentioned as a not allowed use case. Whether the users would agree is not relevant here.
For example, user_posts permission, has "non-visible use of this data such as sentiment analysis or guarding against spam bots" marked with a red "X" for nope.
So the only way of getting your app to request the necessary permission(s) from users, would be to add them as testers to the app via app dashboard/API. Anyone with a role in the app which can be asked for any permission, reviewed or not. Those users would however have to have their accounts verified (mobile/text, credit card) and sign up as a "developer" on the FB platform, before your app could send them requests to become testers.
You'd be flying under the radar with that, so to speak. Facebook offers this "loophole" mainly for the purpose of letting developers test and develop their apps properly, before review. It is also explicitly mentioned in the app development FAQ as a way around the need for review, for specific use cases such as wanting to get your blog posts published to your own FB page automatically. It would not cover what you are trying to do so, but it will likely "work" as long as none of your test users specifically raises a complaint with Facebook ...
Not sure if there is any published limit on the number of test users that can be added to an app, people have asked about that in the past, but AFAIK none is documented or otherwise published by Facebook. If there is one, and it is not completely stopping this approach dead in it's tracks (say, a few hundred per app rather than, five), you could use multiple app ids, if you don't need to relate data between user accounts too much - because the app-scoped user ids will be different per app id, so that could making connections between friends that are in different "app-id test groups" etc. difficult. Or you might have to refer to other, less reliable measures of uniquely identifying them, such as email or profile name.
I have an idea for a Minecraft plugin which will allow users to log into the website associated with the server without requiring registration, all they would require is their Minecraft username.
I'm trying to find the best way to get Auth0 to authenticate users through a custom passwordless strategy, instead of the default email or SMS which Auth0 provide.
The context which I'll be using this in is as follows:
Minecraft username is entered as their login on the site > Magic link is sent to their text box in-game through a custom plugin and listener > User clicks on the magic link and they are authenticated using Auth0 (JWT token for 30-ish days).
Does this sound possible? or is it wishful thinking.
I know I'll need a custom listener to look for requests from Auth0 and something to return the magic links to the user in-game through a java plugin.
I see no reason that it wouldn't be possible, but there are a few factors to take into consideration:
Minecraft chat cannot be assumed private and direct. There are chat logs and plugins that can intercept your messages. Passwordless auth is like communicating a one-time-use password, so why would you send it via insecure means?
If we assume it's secure, typically it's the responsibility of the user to store the JWTs. If this is a vanilla client, you have no method of storing data on the client, so in the end the server is managing JWTs, which kills the entire reason to use them. Otherwise, why not just have the listener add the player to, say, a cache that expires Players after 30 days of not being accessed?
Other than these two kinks that can be worked out, it sounds like a cool idea. Good luck with it!
I've started building a mobile app using Ionic, which in turn uses Cordova underneath. I want to use Parse.com's BaaS, and therefore I'm bound to using their Javascript SDK.
I want my users to signup using their Facebook, Twitter or Google accounts. Parse.com supports only a specific user signup/login using Facebook, but also has a more generic User class to work with.
The thing is, the generic User class requires a password for authentication/signup, and that's exactly what I want to avoid. I'm looking towards using ngCordovaOauth, which allows my users to authenticate using many different Oauth providers, but I don't have a clue how to let that play nicely with Parse.com. Would it be a good or bad to use the Oauth token as the password?
Any thoughts, pointers or code examples?
I just ran into a slightly differently phrased question here on StackOverflow in the .NET section, which pointed me to a tutorial that explains how to do it: https://parse.com/tutorials/adding-third-party-authentication-to-your-web-app
I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)
I'm currently writing a twitter client using javascript, then found out many people reminded javascript developers about not revealing "consumer secret". But they never said why.
So why is it so important to hide my consumer_secret? If anyone want to show my "via My_App" on his app, making the name My_App more famous, why should I worried about anything? After all, you can't get any useful information out of my consumer_secret, the user information is protected by both https and token_secret.
A malicious developer could create a spam application using your consumer secret. If enough spam accounts are using the spam app Twitter may disable the entire consumer key at which point your entire application will no longer work with Twitter.
You can think of the consumer secret as a password -- it identifies your client to the server. Anyone with your consumer secret can pretend to be your app.
So you need to keep it secure, and you don't want to "hide" it; you want to encrypt it. This should happen on the server, never in the javascript app that you send to the user.
You can find a lot of helpful information at Google's support page.