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!
Related
I've a requirement to integrate Auth0 in our project (Reactjs/Hapijs/MySQL). I checked the documentation and they have many examples and that is great, however, I can't find any related to how exactly do I use my existing user database.
In my application I have users and those users can have one or more projects. With the authorization that we currently use, a user logs in, I check what projects does he own and send it to the React application.
I am missing a document that explains me how to use Auth0 and still be able to check in my database what projects user owns.
My idea on how that should work (I might be wrong):
User sends username and password to our server
Our server makes request to Auth0 (with provided credentials)
Auth0 replies back to our server with some token
We look in users table in our database and try to verify the existence of that user
If it is a match then we simply look (as we already do) for user projects.
Is this how it is supposed to work?
There are a few options available for scenarios where you want to integrate Auth0 with applications that already have existing user databases. You can either:
continue to use your existing store
progressively migrate your users from your custom store to the Auth0 store
You don't mention it explicitly, but judging from your expected flow it seems you would be wanting to implement the first option. There is specific documentation that you can follow that explain how you can setup your custom database connection, see Authenticate Users with Username and Password using a Custom Database. It mentions MySQL, but others database servers are supported and there are many templates that will allow you to quickly setup things.
When you complete this the final flow will be the following:
Using either Auth0 authentication libraries (Lock) or your custom UI you'll ask the user for their credentials
Either Lock or your custom UI submits the credentials to Auth0 authentication API
Auth0 authentication API validates the credentials by calling scripts that execute against your custom database (these scripts were provided by you when you configured the database connection)
If the credentials are valid the Authentication API will return a token to the calling application that will have user information and proves the users is who he say he is.
The scripts you need to provide are the following, but only one is mandatory:
Login script (executed each time a user attempts to login) (mandatory)
Create user script
Verify email script
Change password script
Delete user script
The optional scripts are only required when you want to provide the associated functionality through Auth0 libraries, if only need the login to work then you can skip them. The login script, in the case of a valid user, is also where you return the profile information of the user, for example, you could in theory include their owned projects in the user profile.
I'm newbie to Facebook Graph API and Facebook JavaScript SDK but I'd like to know some things:
Is there any way to put my Access Token in a Open Source application without actually showing it? I'm using GitHub and for security purposes I'd like to make it private.
Can I show my user information without asking the users to Authenticate themselves?
Where in Facebook Developers App can I allow more "scopes" to share publicly? For example, user_photos, user_posts, user_likes, user_status, etc...
These "scopes" that Facebook allows by default are actually the information I'm getting from the user while I'm Authenticating them right?
Just to clarify what I'm trying to do, I want to share things about my Facebook Account through the Facebook Graph API in the gh-pages branch on GitHub, but I don't like the idea of having to authenticate every single user that has access to the page.
I'd like to make my user information public, but don't want to show my access token, because it's Open Source and it can get dangerous eventually.
If you'd like to see my repository and have a better understanding of the project. You can access https://github.com/iszwnc/rye
If I recap:
you don't want to share your app access token (good!),
you don't want your users to authenticate.
Basically, you can't hide your token and let your users query Facebook directly. You need some server-side code on a machine that would be the only one reaching Facebook. Your server would play the role of an interface between Facebook and your users. So you will have to:
do the API calls from a server using server-side code (i.e. Node.js),
save the information you want in a database. This is optional but better to avoid the same information to be retrieved multiple times, thus avoiding your future 100 users to (voluntarily or not) reach your app API limit.
let the users query your server using some client-side code (i.e. AngularJS) in order to retrieve what you and only you know (remember, you own the token).
About Github, don't share your token on it. People can generate their own token if they want to run your app. Here are several suggestions:
Add your token to an environment variable which you can set just before launching the app (don't forget to mention that in your README),
Add your token to a file:
Create a credentials.js file that contains an empty token:
// Please use your own token
var APP_TOKEN = '';
Commit the file to Github,
Have a .gitignore file that contains the credentials.js,
var APP_TOKEN = 'now-you-can-put-your-token-here';
Good luck with your project, it looks exciting :-)
I'm new with angularjs...
I read the docs, and completed the tutorial; i also tried something else by myself, and things start to make sense to me.
Now i wonder how to make a safe authentication system.
The easy part: no code, i will describe operations my code execute:
I've a classic form: username, and password text input.
The user fills the form, and press ENTER.
An ajax request starts, and the response is a JSON telling me
something like "ok i know you" or "i don't know who you are".
What i need now is to mantain the logged status of the visitor (or not logged) between the different views of my application.
I read on the internet that, to achieve this objective, someone sets a variable ($scope.isLogged = true), someone else uses cookies; but javascript variables, and cookies can be easily edited using firebug, or similiar development tools.
... and finally the question:
So, have you some suggestion to achieve a safe authentication system in an angularjs app?
You cannot authorize anything in angularjs, because the user has full controll of the execution environment (namely, the browser). Each check, case, if - anything you can think of - can be tampered with. There are javascript libraries that use asymmetric keys to perform local encryption to store local data somewhat safely, but they are not what you are looking for, really.
You can, and you should, authorize things on the server - the standard way you would do it in an ordinary application - using session; no special code is necessary, ajax calls use ordinary session cookies. Application does not need to know whether it's authenticated or not. It only needs to check what server thinks.
From the perspective of your angularjs application, being "logged in" or "logged out" is merely a gui hint for the user.
Probably you found a solution, but currently I made up an authenticaiton scheme I'm implementing in my Angular App.
On .run the app is registered with an ActiveSession set to false.
It then checks if the browser has a cookie with a token and a userId.
If YES, check token+userId on server and updates the token on both server and local (token it's a server generated key unique for each user)
If NO shows login form, check credentials and again if they are valid does a server request t get a new token and saves is locally.
The token is used to make a persistent login (remember me for 3 weeks) or when user refreshes the browser page.
Thank you
I asked this question three months ago.
I would like to share what has become my favourite approach when I've to deal with user authentication in a web app built over AngularJS.
Of course fdreger's answer is still a great answer!
You cannot authorize anything in angularjs, because the user has full
controll of the execution environment (namely, the browser).
From the perspective of your angularjs application, being "logged in"
or "logged out" is merely a gui hint for the user.
So, briefly my approach consists in:
1) Bind to each route additional information about the route itself.
$routeProvider.when('/login', {
templateUrl: 'partials/login.html', controller: 'loginCtrl', isFree: true
});
2) Use a service to mantain the data about each user, and their authentication status.
services.factory('User', [function() {
return {
isLogged: false,
username: ''
};
}]);
3) Everytime the user try to access a new route, check if they have the grant to access.
$root.$on('$routeChangeStart', function(event, currRoute, prevRoute){
// prevRoute.isFree tell me if this route is available for all the users, or only for registered user.
// User.isLogged tell me if the user is logged
})
I also wrote about this approach (more in detail) on my blog, users authentication with angularjs.
First of all: Client-side data can always be manipulated or tampered with.
As long as valid session IDs aren't easily guessable and measures like associating session tokens with the client's IP there is no big deal about it.
You could, in theory, also encrypt the cookie, as long as you do so on the server side.
For details on how to encrypt your cookies, see the docs of your server-side (e.g http://expressjs.com/api.html#res.cookie for Express.js)
You need to learn about the server side / database end of it.
User logins need to be stored somewhere - 99.9% of the time this is in a server side database.
Ideally for a really secure system you want a backend (server side) membership system that stores the session in a database table that is related to the member table that holds the encrypted password, but also provides a RESTful interface where you can build your api calls to.
One Script that I've used successfully a lot has been Amember https://www.amember.com/. It's a really cost effective way to go although there are a lot of other script out there, I've had a lot of success with this one.. It's also PHP so you can build your build out an API for your angular http calls really easily.
All of these javascript frameworks are great but the effect is that now too many are focusing too much on the front end of things - learn the database / backend as well! :-)
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.