Authenticate meteor users from an external application - meteor

I have a meteor application (with meteor Accounts), and am building a mobile application. How do I authenticate users from the mobile app. I have a python webservice that can send data to mobile clients. But I have no clue how to authenticate from the external app.
I did look at DDP client, but there is no 'authenticate method'. Is there any way to do this with a pure python solution? I have access to the 'users' collection -> srp verifier and salt.
Note: Python srp didn't work. The salt and verifier generated by python srp are supposedly bytes. However I can't even decode them using bytes.decode(encoding)

It sounds like you want to use the out-of-box account management baked into Meteor, then surface a mechanism that your PHP code can call to show different information based on who is authenticated.
If that's correct, I think your best bet is:
Build a PHP DDP Client. Meteor isn't really built to expose webservices in a traditional sense, but rather surface what they call a DDP protocol for external sources to plug into the server-side publications. That said, I have not yet found a PHP DDP client, but here is one in node, and one in .NET. You'll want to build a PHP DDP client and then write a Meteor.method in the Meteor server code that you can remotely call from your DDP client to check for a user's authentication.
BUT, if all you're doing is surfacing marketing information in your PHP site, perhaps it makes more sense to either (1) keep the entire app in PHP and use a native PHP account management system, or (2) save yourself the trouble of the DDP overhead and write the exposed marketing page directly in the Meteor app? If you need to keep it from a different server, consider a simple iframe?

I just developed a DDP client for PHP, which might be what you need. Check it out here :
https://github.com/zyzo/meteor-ddp-php

Related

Firebase custom auth in server-to-server scenario

I need to implement a scenario where, after a file is uploaded to Google Cloud Storage, a function is triggered and processes the file. In this case, processing basically means sanitizing the file, storing it into Firestore and making it accessible via another HTTP-triggered function (a REST API of sorts).
Both user-facing ends of this process (a file upload and HTTP function) need to be secured. The process will be used in server-to-server scenario: one side is going to be a backend written in either Node.js or .NET, the other will be my Firebase solution (Cloud Storage and HTTP-triggered function as per above). In Firebase, I am going to maintain a custom set of users that should have access to the system - my idea was to use a simple system where each user will have a client id and a client secret (basically an oAuth client credentials grant type).
Based on what I read online, an only option to implement this is to use [Firebase auth with custom tokens][1]. I found lots of examples online on how to do that, but it was always about client-to-server scenarios (e.g. a Javascript web app talking to REST API). Server-to-server scenarios were not mentioned anywhere and indeed, I am unsure how to go about implementing it - I can call auth.createCustomToken(uid) just fine in my HTTP Firestore function, but there seem to be no server-side libraries I could use to call auth.SignInWithCustomTokenAsync(customToken).
To sum it up:
How can I use Firebase auth with custom tokens in server-to-server
scenario, where I need to sign in using a previously generated
custom token from a server environment?
If it is not possible,
what's the other alternative to securely implement the
above-described architecture?
I've contacted Google Support and if anyone else is struggling with this, in server-side scenarios, recommended approach is to call signInWithCustomToken endpoint in Firebase Auth REST API.

AWS CloudWatch with mobile applications

I have a backend system built in AWS and I'm utilizing CloudWatch in all of the services for logging and monitoring. I really like the ability to send structured JSON logs into CloudWatch that are consistent and provide a lot of context around the log message. Querying the logs and getting to the root of an issue is simple or just exploring the health of the environment - makes CloudWatch a must have for my backend.
Now I'm working on the frontend side of things, mobile applications using Xamarin.Forms. I know AWS has Amplify but I really wanted to stick with Xamarin.Forms as that's a skill set I've already got and I'm comfortable with. Since Amplify didn't support Xamarin.Forms I've been stuck looking at other options for logging - one of them being Microsoft's AppCenter.
If I go the AppCenter route I'll end up having to build out a mapping of the AppCenter installation identifier and my users between the AWS environment and the AppCenter environment. Before I start down that path I wanted to ask a couple questions around best practice and security of an alternative approach.
I'm considering using the AWS SDK for .Net, creating an IAM Role with a Policy that allows for X-Ray and CloudWatch PUT operations on a specific log group and then assigning it to an IAM User. I can issue access keys for the user and embed them in my apps config files. This would let me send log data right into CloudWatch from the mobile apps using something like NLog.
I noticed with AppCenter I have to provide a client secret to the app, which wouldn't be any different than providing an IAM User access key to my app for pushing into CloudWatch. I'm typically a little shy about issuing access keys from AWS but as long as the Policy is tight I can't think of any negative side-effects... other than someone flooding me with log data should they pull the key out of the app data.
An alternative route I'm exploring is instead of embedding the access keys in my config files - I could request them from my API services and hold it in-memory. Only downside to that is when the user doesn't have internet connectivity logging might be a pain (will need to look at how NLog handles sinks that aren't currently available - queueing and flushing)
Is there anything else I'm not considering or is this approach a feasible solution with minimal risk?

Stormpath for JWT authentication/authorization with Azure

We are looking into authentication/authorization for a mobile reporting app which consumes hourly/weekly/monthly commercially sensitive data over the wire using an internally provided RESTful web api service running within the MS Azure Cloud.
Stormpath's offering looks interesting in that it would appear to provide some heavy lift for the whole identity management side of things, registering users, authenticating them and producing JWT tokens etc.
Otherwise, we would have to write our own auth/user db tables and have some management overhead with that.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Can anyone, especially those familiar with Stormath elaborate on this?
I get that all the user registration, password recovery use cases would go via Stormpath and I am guessing that JWT token creation for a user would require our existing service to talk to Stormpath. Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
I guess I am sensitive to performance issues regarding the whole token validation step within the Web API pipeline.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet.
Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
One thing which looks attractive about something like Stormpath is the possibility of two factor authentication.
Without having gone into too much analysis yet, a typical use case scenario would be that sign up or password recovery would mandate that an SMS was sent to the user's preregistered smartphone number to provide a stronger validation that they (and their pre-registered device) are the intended user of the mobile app which uses the RESTful service to consume and visualise commercially sensitive data.
I work at Stormpath on our .NET libraries.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Stormpath acts as your API's source of access tokens. When someone using your mobile app needs to log in, your backend API uses Stormpath to generate an access token, or the mobile app talks directly to Stormpath to get an access token. Either way, the token allows the mobile app to make authenticated requests to your API.
Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
The access token (JWT) integrity can be validated locally using middleware like UseJwtBearerAuthentication in ASP.NET. For more security, you can send the token up to Stormpath to be verified even further (for revocation and other cases), but the tradeoff is a network request. Local (fast) validation is the default, but we give you both options.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet. Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
Using either Stormpath or Azure AD B2C is "outsourcing" your identity and user management. The benefit is that you don't have to write it yourself, and you can focus on writing your business and app logic instead. The features are similar, although Stormpath is a little more flexible on the mobile side of things (since you aren't forced to use a browser/page-based flow).

Connecting Firebase Simple Login and External Server

How would you use Firebase's simple login to allow users to upload music files.
As I understand it, it doesn't make sense to even think about storing audio files in Firebase's database which is why I would like to be able to store them on an external PHP server.
So, the question revolves on whether I can use Firebase's simple login system to allow users to authenticate to an external server.
I have seen Using NodeJs with Firebase - Security ... which gives some great insight, but then how would you enable the large file upload to the external server?
The technique from the answer you linked will work for your situation too, you just need to translate it into PHP and the Firebase REST APIs. Additionally, since the REST API isn't real-time you must add some kind of task queue that it can poll.
Your program would flow something like this:
User logs in to Firebase with Simple Login
User write to only a place that they can (based on security rules). The user also writes an entry into a task queue.
Your PHP server connects with a token that allows reads of all of the user's secret places.
Your PHP server polls the firebase every once in awhile to look for new tasks. If there's a new task, it validates the user and allows that user to post data to it.
All that being said, this is going to be pretty complicated. PHP's execution model does not lend itself well to real-time systems, and
I strongly recommend you consider some other options:
You're using a cloud platform, Firebase, for your realtime stuff, so consider a cloud service for your binaries too, like filepicker.io
If you really want to host the files yourself, use something that's more real-time like node.js. It'll save you the effort of constructing that task queue.

Track changes in client and send to server

I am planning a 3-tiered architecture in which I need to track changes to domain objects on the client (a Windows Store app) then send those changes back to the server (an Azure worker-role). I just found out about WCF Data Services which I can run on the client and integrate with Entity Framework Code First on the server. It looks okay but I'm wondering what other tools may also be available.
Are there any alternatives to WCF Data Services for tracking changes in client then sending them to server? If available, I'd like a solution that doesn't require generated DTO classes but instead sends the deltas alone.
Have you considered using rest services?
Im not an AZURE user, but use elsewhere.
Azure rest services docu

Resources