This looks amazing! Great work - will have to try it out. On 7 May 2017 at 23:03, Dascalita Dragos <[email protected]> wrote:
> Recently I’ve been trying to see if we can reuse PassportJS with OpenWhisk > in order to create a User Authentication experience in a Serverless > fashion. PassportJS is a Node library that supports 300+ authentication > providers and this is what made it appealing. > > The use-case I was after was to enable developers to authenticate users > with multiple providers. > > As an example: when users backup, upload, or edit a photo in a Cloud > Storage service, register a webhook as an action that automatically syncs > the photo with another Cloud Storage service. For such a scenario the > action needs 2 tokens, one for each service, in order to access user's data > in both places. > > My first step was to see if we can run PassportJS in an OpenWhisk action, > without having to depend on an Express server. This action would be > responsible with user authentication, without being concerned with storing > any user tokens; the assumption is that other actions could handle this > concern of caching tokens in a secure way, and making them available to the > actions that need them. So the “authentication” action would only reuse > PassportJS, login users, and output the tokens. > > Eventually I was able to adapt PassportJS to an OpenWhisk action. You can > find the code here: > https://github.com/ddragosd/experimental-openwhisk-passport-auth > > The good news is that with less than a couple of hundreds LOC OpenWhisk & > PassportJS can authenticate users in a lot of systems. So far I’ve tried > authentication with GitHub, Twitter, Facebook, and Google, and it works > flawlessly. The code of the action is ~240kb, including the libs supporting > these providers. > > The tricky part was to decouple Passport from Express / Connect, by > providing simple implementations for request/response objects, as they > should work differently in a serverless environment; this resulted in a > fine-grained level of control for the response of the action, which proved > to be useful. > > The way the action works is that developers can create multiple OpenWhisk > web actions reusing the same code, an action for each provider; for each > action they get to set default parameters like client_id, client_secret, > scope, corresponding to each provider. Each provider has its own unique > URL. > > It would be nice if we can make it straight forward in OpenWhisk for > developers to create actions that listen to events from a variety of 3rd > party providers on behalf of the users, and then be able to do something > useful on user’s behalf; user authentication plays an important role in > this. To some extent I’ve also been thinking what it would be like for > developers if this feature would come with the OW catalog. > > > Looking forward to hearing your feedback, > > Dragos > -- Regards, James Thomas
