Software Ecosystem help needed

I’ve been pottering with the capitalist project for a while now. And by pottering I really mean ‘gotten to a point, become stuck and stopped’. For those not familiar, capitalist is my project to do small scale ledgering and management of the Stripe API so that we can do payment processing at HSBNE.

So my problem is around authenticating users, and its a really sticky wicket. Where to start. A wild diagram appears:

So Blastoff is a name I just picked for a theoretical member sign up and induction app that might eventually exist. Capitalist is the app that manages a ledger, so payments and withdrawals. Seltzer is our membership database system that we’re currently porting towards, and Vendo Is any given rfid-ised vending machine.

It’s safe to assume that these apis have some authentication between them so that we can trust information coming from Blastoff to Capitalist.

Right? Right.

Problem 1

As far as I understand OAuth2.0, theres no way for Blastoff to go through the authentication process (ie, click here to sign into your provider, see a consent screen, app gets access) and then pass that authentication on. Capitalist needs to be able to say that you authorised a payment, so whatever app talks to capitalist needs to provide some token that capitalist can authenticate and say ‘yes, John Doe wants to pay $60 for membership’.

To be clear, when you say to Capitalist, with <sometoken>, Capitalist can verify that email address with the provider so that we know that we are authorized to bill you or shift money around, and that whomever made the request didnt pass through a bogus email/account identifier.

Theoretically the app to app authentication is enough, but I’m not exactly convinced?

Problem 2

This is the same problem from a different angle. When you swipe your card at a vending machine (something you have) you should provide a pin (something you know) and that should be authenticated by Seltzer. In this scenario, our authentication source is not OAuth via google or similar but Seltzer. The problem is that we’re doubling up on who provides the user information.

Question 1

Should we rely just on the app to app authentication, and trust that the user identifications we pass around are authorized? If not, how do we check?

Question 2

If we bounce back to the oauth provider always to check for authority to act on an account, how do we pass that between apps?

Question 3

If we can’t share that checking functionality between apps, how do we manage the multiple consent screens that a user might hit? It seems shitty to me that when a new member signs up with Blastoff they might see a consent screen for that, Capitalist and Seltzer one after the other.

Question 4

If your first interaction with the system is via Vendo and our authority source is oauth and you’ve never gone through a browser, what happens then? We can’t make you sign into google on a vending machine.


So we’ve been talking on IRC a little bit, shockdesign and myself. We’ve come up with some thoughts.

Question 1 & 2 Auth wherever makes sense and pass an email and ID Token around and APIs are responsible for authenticating that user session.

Question 3

Solved by above

Question 4

Something turns RFID+PIN into Email+IDToken. Seltzer? If you’ve never signed in thats tricky. Should we support some alternate form of auth universally across our codebases? That sounds… involved. We could make some sort of lightweight app thats only job is to manage oauth sessions and auth rather than seltzer perhaps. Then we could make it fairly painless via QRCode and smartphones.

Can we not when we sign up for oauth from Google (examp) Have an API Key
and a Wildcard domain?

Then anything with our secret api key and a hostname or or makes a call its the same auth,
ie allow one, allow all?


add blastoff functions to seltzer so it does all the handling of user data
and capitalist calls seltzer for user verification when processing payments?

Or am I completely wrong here?

I’m not sure if google allows you to auth against an entire domain, it seems to be against apps specifically. Someone with a better understanding might prove me wrong.

What you describe, secret api key stuff, is the app to app authentication. Thats easy, this is more about proving that when something asks an app to do something in the name of user x, that we can verify that user x is correct.

As for adding functionality to existing apps, I’m really really hesitant to do that. So far we’ve gotten by really well by going by the unix philosophy of small apps that do one thing well and can talk to each other. Even if we did merge those two apps (and its a bad idea for other reasons, ie security), we still need to authorise the user. So it doesn’t solve the main question.