I've been working on a authorization service. It's a somewhat complex project, so I think it'll look good on a portfolio, but also it is a way to remove the reused code for every app I build. Just one central app where users are created, edited, allowed to set up security preferences and select what information to share. Users can have an account on my auth app, and share some info with other apps.
So not only do I have a create users, I've also given them the ability to create organizations and control certain requirements for auth on their apps, as well as create roles for users that have created an account on their app. This is where I'm having some issues. I'm using access and refresh tokens, rsa key pairs and jwts to authenticate each users on my site, but when creating an organization, I want to allow users to have multiple organizations if they want, and each organization should have it's own set of keys. While each individual org can set up their own authorization implementation after obtaining user info, they can only get that user info from the authorization server if they have the key associated with that app.
My problem is I don't know how I should implement this. I feel like I'll have to generate rsa keys, save one key to a database and have the organization save the other as a env variable. But should I save the public key to a db or the private? How do I even save a pem file to a db without changing the value? I'm just a bit lost on how this process can be accomplished with security in mind, but also while being dynamic. If I have to store private keys in my db then I'm very concerned about security as well. Can anyone break this down for me?
TLDR: trying to make google style universal login, need help storing and verifying rsa keys for organizations.
Related
I want to add a new data to firebase authentication which has data like displayname, phone number, image. But i want to add more such gender, birthday and more. is it possible to add new?
There is no way to add arbitrary additional data to Firebase Authentication user profiles. If you want that, consider using the Firebase Realtime Database (or Cloud Firestore) for storing the additional information.
This approach has been covered in quite a few questions in the past, so I'll link you to those:
Firebase: setting additional user properties
Add extra User Information with firebase
How do I link each user to their data in Firebase?
Swift & Firebase - How to store more user data other than email and password?
Store additional information during registration with Firebase in Android
How to add additional information to firebase.auth()
Since a few weeks ago you can add small bits of information to the Firebase Authentication user profile. While this might sound like what you need, it is explicitly not meant for storing user metadata such as you need. Instead this is intended for storing so-called claims: properties about the user that you then access in the security rules. See the documentation for setting custom claims.
I had the same problem when introducing user roles for authorization in my React with Firebase application. Somehow I wanted to be able to pass a roles property to the authenticated user, but found myself again in Firebase's restrictive framework of doing it their way.
I found a way around it by (1) managing users myself in the Firebase database and (2) merging the authenticated user with the database user when the application loads. Then I am able to add additional user properties (e.g. roles) to my database user, because it will be merged with the authenticated user anyway.
If you are interested in this approach, checkout this tutorial.
I'm working on a React-Redux web-app which integrates with AWS Cognito for user authentication/data storage and with the Shopify API so users can buy items through our site.
With both SDKs (Cognito, Shopify), I've run into an issue: Their core functionality attaches data behind the scenes to localStorage, requiring both SDKs to be run client-side.
But running this code entirely client-side means that the API tokens which both APIs require are completely insecure, such that someone could just grab them from my bundle and then authenticate/fill a cart/see inventory/whatever from anywhere (right?).
I wrote issues on both repos to point this out. Here's the more recent one, on Shopify. I've looked at similar questions on SO, but nothing I found addresses these custom SDKs/ingrained localStorage usage directly, and I'm starting to wonder if I'm missing/misunderstanding something about client-side security, so I figured I should just ask people who know more about this.
What I'm interested in is whether, abstractly, there's a good way to secure a client-side SDK like this. Some thoughts:
Originally, I tried to proxy all requests through the server, but then the localStorage functionality didn't work, and I had to fake it out post-request and add a whole bunch of code that the SDK is designed to take care of. This proved prohibitively difficult/messy, especially with Cognito.
I'm also considering creating a server-side endpoint that simply returns the credentials and blocks requests from outside the domain. In that case, the creds wouldn't be in the bundle, but wouldn't they be eventually scannable by someone on the site once that request for credentials has been made?
Is the idea that these secret keys don't actually need to be secure, because adding to a Shopify cart or registering a user with an application don't need to be secure actions? I'm just worried that I obviously don't know the full scope of actions that a user could take with these credentials, and it feels like an obvious best practice to keep them secret.
Thanks!
Can't you just put the keys and such in a .env file? This way nobody can see what keys you've got stored in there. You can then access your keys through process.env.YOUR_VAR
For Cognito you could store stuff like user pool id, app client id, identity pool id in a .env file.
NPM package for dotenv can be found here: NPM dotenv
Furthermore, what supersecret stuff are you currently storing that you're worried about? By "API tokens", do you mean the OpenId token which you get after authenticating to Cognito?
I can respond to the Cognito portion for this. Your AWS Secret Key and Access Key are not stored in the client. For your React.js app, you only need the Cognito User Pool Id and the App Client Id in your app. Those are the only keys that are exposed to the user.
I cover this in detail in a comprehensive tutorial here - http://serverless-stack.com/chapters/login-with-aws-cognito.html
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 have been learning with Angular.js and used Parse as the back-end service. To post data to the Parse RESTful API, you would pass REST API key and App ID in the header of the request like this:
var config = {headers: {"X-Parse-REST-API-Key":"someapikey", "X-Parse-Application-Id":"someappid"}};
$http.post("https://api.parse.com/1/classes/myobject", obj, config).success (
function(data) {console.log(data);}
);
While this is great for learning, I am wondering how would the RESTful API for Parse or any other Backend-as-Service vendor work in a real html application. The API key and application Id would be exposed in JavaScript and anyone smart enough to view source could modify data to your account.
The only way I can image this to work would involve a proxy server that adds to Api Key/App Id header. However, this would defeat the purpose of not having to run your own back-end server. Am I missing something here?
Here's what you're missing :)
The Parse.com REST/JavaScript keys are designed to be "out-in-the-wild." With these keys it's not possible to get around object access rules or beforeSave validations. Only the master key can do this. Protect the master key. A useful analogy is public-key encryption: you need share your public key but protect the private key.
Can anyone modify your data? Yes, but only if you let them. Can users query data belonging to other users? Yes, but again only if you let them. Parse has a few ways to ensure data integrity and security.
The first is per-object permissions. Use the Parse.com web interface to set a) whether or not classes can be created on the fly and b) CRUD permissions for existing classes. One of the easier steps to securing an app is to disable any class permissions not explicitly required. For example, objects created on the back-end which do not need to be writable (or perhaps readable) by end users.
The second is access control lists (ACLs). ACLs are set on each record. They specify which users or roles can read or write the record. Records without an ACL are public (any user can find it). If Sue creates a record that should be private to her, set an ACL as such. Tom won't be able to find it without the master key.
The third is Cloud Code. You're able to enforce mission critical business rules and data validations using beforeSave/afterSave functions. Determine what is truly important, and make sure it's validated against in these functions. It's also a good idea to set the ACL explicitly in these functions. ACLs can be passed in when creating the object, but it's possible for the end user to tamper with these.
Here is are summary rule of thumbs for security and integrity.
Object permissions should only be as open as necessary to support your requirements.
Every record should have an ACL, unless you're sure it shouldn't.
Most ACLs should be set with before/afterSave functions.
Any validations that must be enforced should checked for in before/afterSave functions.
Last thing: it's temping to think of all business logic as "important" and insist on "perfect integrity." This is overkill for many apps. Make sure you have enough server-side protection in place such that one user can never cause harm to you or to your other users. There is not much sense in worrying much beyond this (other than support costs). If someone is experimenting with your app but is prevented from intentionally or unintentionally interfering with others, maybe they'll find a whole new way to use it :).
Parse provides several access keys that can be used via different APIs:
Client key (for use from iOS and Android applications)
Javascript key
Windows key
REST key
Master key (to be used for REST API access, but not conforming to object ACL permissions)
When accessing Parse from client-side javascript, you should use the javascript API with the Javascript access key.
In terms of security, you will not be able to prevent users from using an access key that is used by client side javascript. Parse provides powerful access control via ACLs attached to each object, allowing you to restrict read/write access to each class to specified users. You can also prevent clients from creating new classes in the settings of your app. Take a look at the security guide here.
I'm trying to write a javascript single-page-app that allows users to login and then, once logged in, create/modify records in a database. I'd like to avoid having my own server side scripts if possible, instead using something like Parse.com, Kinvey.com, or Cloudmine.me.
My issue is that these services have user login capacity but use API keys to determine whether your app has write access. They don't seem to let you have write access once your user is logged in. The only way I can think of to accomplish this is to store a write-access API key in the user's user data, so I'd have the user login, fetch the hidden API key, then change the API key of the app to use that one, so they'll have write access. Obviously this isn't very secure because once that API key is sent over the network, that user will have write-access even if we delete their account or they change their password.
Perhaps I'm going about this the wrong way, so feel free to let me know. Hopefully this made sense. Thanks!
You should be able to restrict access to a group of users using Parse.ACL: http://www.parse.com/docs/js/symbols/Parse.ACL.html
If you want to control access on a per user basis then you will have to maintain a custom property on the user object. Then you can check the custom property in the BeforeSaveRequest() function and decide whether the user has write access: http://www.parse.com/docs/js/symbols/Parse.Cloud.BeforeSaveRequest.html
By default, most BaaS providers should provide collection level security and some even offer per entry security via ACL's (Access Control Lists).
Kinvey for instance has several variations on collection level security:
http://devcenter.kinvey.com/html5/guides/security#Collectionlevelpermissions
The default security level of Shared make it so the user has access to read everything in the collection but can only write to their own items. You may also want to use the Private security level to make it so you can only read and write to your own items.
If you want to have more fine-grained control over security you can utilize entry level permissions:
http://devcenter.kinvey.com/html5/guides/security#Entitylevelpermissions
With entry level permissions you can give fine grained access to a specific user or groups of users that you manage. You can even determine what level of security a user has to your entry, read or write. If you have a need to go even finer with control you have full access to write your own security utilizing Business Logic.
Full Disclosure - I am an engineer at Kinvey.