PassportJS with OpenWhisk

[Dascalita Dragos <dd...@gmail.com>]

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

Re: PassportJS with OpenWhisk

[Matt Rutkowski <mr...@us.ibm.com>]

This is such a great thought and piece of work.  Plan to try this myself 
perhaps after ApacheCon...  would like to make it a Sample (new repo.) 
"app" and add support for wskdeploy.

Kind regards,
Matt 




From:   Dascalita Dragos <dd...@gmail.com>
To:     "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
Date:   05/07/2017 05:04 PM
Subject:        PassportJS with OpenWhisk



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

Re: PassportJS with OpenWhisk

[Matt Rutkowski <mr...@us.ibm.com>]

Good news though... wskdeploy has added ZIP support... so we can do this 
for you if you create a manifest.  If it doesn't work for some reason or 
another open an issue and I am sure Daisy or David can make it work.  In 
fact, would like this to be featured in wskdeploy as a use case in the 
spec and test cases.

-Matt



From:   Dascalita Dragos <dd...@gmail.com>
To:     dev@openwhisk.apache.org
Date:   05/08/2017 06:54 PM
Subject:        Re: PassportJS with OpenWhisk



Thanks everyone for the feedback.

> "...we currently don't have passport installed in nodejs6action runtime,
to use your repo as is today I need to create a zip first, can't use the
.js as your doc show right?..."

Actually no. I've used browserify to combine the dependencies into a 
single
JS. That's how I highlighted that it's only ~240Kb.

For the fun of it, I've quickly deployed it in Bluemix, in case you want 
to
try it out for yourself:
https://openwhisk.ng.bluemix.net/api/v1/web/oauth_test_oauth_space/oauth/github


> "...Don't know if you saw last post from Lionel [1] uses a webaction to
wrap an existing express app..."
That looks fantastic. I've also taken a similar approach, adapting the
request and response for Passport. It would be interesting to try it out
with openwhisk-express NPM and see how it goes.

"...very interesting to the point of creating an action that can be shared
as standard middleware in OpenWhisk apps, in terms of composition..."
Yes, at the end of the day w or w/o Express this is what I was trying to
achieve.



On Mon, May 8, 2017 at 11:24 AM Carlos Santana <cs...@gmail.com> 
wrote:

> This is awesome Dragos +1
>
> I think everybody by now realize that with web actions and having access 
to
> the request and response, there is a lot of modules in ExpressJS that 
cab
> be leverage in OpenWhisk without re-inventing the wheel (web server) :-)
>
> Don't know if you saw last post from Lionel [1] uses a webaction to wrap 
an
> existing express app, my proxying the request and response.
> I think he publish some initial work on npm [2] and github [3]
>
> I think he is planning on part 2 of the article to include 
authentication
>
> You work is very interesting to the point of creating an action that can 
be
> shared as standard middleware in OpenWhisk apps, in terms of 
composition, I
> think it feats very well in a sequence composition were this action will 
be
> the gatekeeper to handle the auth and get the user token which outputs 
to
> the next action which doesn't have to be a webaction it can be a
> traditional action.
>
> The output of the traditional action, would then be pass to an action 
that
> knows how to build the http response (i.e. statusCode, headers, body), 
as
> you can see there can be action in the center of the sequence that never
> new they were in the middle of a request/response flow.
>
> Rodric coined the term "webify" an traditional action, where 
thissequence
> action can be created with an Action, as you can see we like to eat our 
dog
> food a lot META !!
>
> I think there is a need for both a library and a package that offers 
this
> helper functions, that people don't have to re-invent just to make web
> actions handle expressjs middleware.
>
> In terms of delivering this package in openwhisk-catalog repo, I think I
> want to go in opposite direction right now it's a big monolithic repo 
that
> I want to break out into individual repositories.
>
> So I proposed having a repository named something like
>  "openwhisk-express", we can put the npm libraries/modules and re-usable
> actions in this repository and deploy them to openwhisk by default as 
part
> of postdeploy step that today we only deploy catalog packages, but we
> should also deploy the other packages in OpenWhisk like alarms, kafka,
> etc..
>
> Having in it's repo also makes it easy to deploy it with wskdeploy in 
case
> you have your own copy or different version of the package
>
> One minor comment on your README that I didn't follow, we currently 
don't
> have passport installed in nodejs6action runtime, to use your repo as is
> today I need to create a zip first, can't use the .js as your doc show
> right?
>
> [1]
>
> 
https://medium.com/openwhisk/deploying-express-js-apps-to-openwhisk-part-1-9133ba5f262c

> [2] https://www.npmjs.com/package/openwhisk-expressjs
> [3] https://github.com/lionelvillard/openwhisk-expressjs
>
>
> --Carlos
>
>
> On Mon, May 8, 2017 at 11:30 AM James Thomas <jt...@gmail.com> 
wrote:
>
> > This looks amazing! Great work - will have to try it out.
> >
> > On 7 May 2017 at 23:03, Dascalita Dragos <dd...@gmail.com> 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
> >
>

Re: PassportJS with OpenWhisk

[Dascalita Dragos <dd...@gmail.com>]

Thanks everyone for the feedback.

> "...we currently don't have passport installed in nodejs6action runtime,
to use your repo as is today I need to create a zip first, can't use the
.js as your doc show right?..."

Actually no. I've used browserify to combine the dependencies into a single
JS. That's how I highlighted that it's only ~240Kb.

For the fun of it, I've quickly deployed it in Bluemix, in case you want to
try it out for yourself:
https://openwhisk.ng.bluemix.net/api/v1/web/oauth_test_oauth_space/oauth/github

> "...Don't know if you saw last post from Lionel [1] uses a webaction to
wrap an existing express app..."
That looks fantastic. I've also taken a similar approach, adapting the
request and response for Passport. It would be interesting to try it out
with openwhisk-express NPM and see how it goes.

"...very interesting to the point of creating an action that can be shared
as standard middleware in OpenWhisk apps, in terms of composition..."
Yes, at the end of the day w or w/o Express this is what I was trying to
achieve.



On Mon, May 8, 2017 at 11:24 AM Carlos Santana <cs...@gmail.com> wrote:

> This is awesome Dragos +1
>
> I think everybody by now realize that with web actions and having access to
> the request and response, there is a lot of modules in ExpressJS that cab
> be leverage in OpenWhisk without re-inventing the wheel (web server) :-)
>
> Don't know if you saw last post from Lionel [1] uses a webaction to wrap an
> existing express app, my proxying the request and response.
> I think he publish some initial work on npm [2] and github [3]
>
> I think he is planning on part 2 of the article to include authentication
>
> You work is very interesting to the point of creating an action that can be
> shared as standard middleware in OpenWhisk apps, in terms of composition, I
> think it feats very well in a sequence composition were this action will be
> the gatekeeper to handle the auth and get the user token which outputs to
> the next action which doesn't have to be a webaction it can be a
> traditional action.
>
> The output of the traditional action, would then be pass to an action that
> knows how to build the http response (i.e. statusCode, headers, body), as
> you can see there can be action in the center of the sequence that never
> new they were in the middle of a request/response flow.
>
> Rodric coined the term "webify" an traditional action, where thissequence
> action can be created with an Action, as you can see we like to eat our dog
> food a lot META !!
>
> I think there is a need for both a library and a package that offers this
> helper functions, that people don't have to re-invent just to make web
> actions handle expressjs middleware.
>
> In terms of delivering this package in openwhisk-catalog repo, I think I
> want to go in opposite direction right now it's a big monolithic repo that
> I want to break out into individual repositories.
>
> So I proposed having a repository named something like
>  "openwhisk-express", we can put the npm libraries/modules and re-usable
> actions in this repository and deploy them to openwhisk by default as part
> of postdeploy step that today we only deploy catalog packages, but we
> should also deploy the other packages in OpenWhisk like alarms, kafka,
> etc..
>
> Having in it's repo also makes it easy to deploy it with wskdeploy in case
> you have your own copy or different version of the package
>
> One minor comment on your README that I didn't follow, we currently don't
> have passport installed in nodejs6action runtime, to use your repo as is
> today I need to create a zip first, can't use the .js as your doc show
> right?
>
> [1]
>
> https://medium.com/openwhisk/deploying-express-js-apps-to-openwhisk-part-1-9133ba5f262c
> [2] https://www.npmjs.com/package/openwhisk-expressjs
> [3] https://github.com/lionelvillard/openwhisk-expressjs
>
>
> --Carlos
>
>
> On Mon, May 8, 2017 at 11:30 AM James Thomas <jt...@gmail.com> wrote:
>
> > This looks amazing! Great work - will have to try it out.
> >
> > On 7 May 2017 at 23:03, Dascalita Dragos <dd...@gmail.com> 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
> >
>

Re: PassportJS with OpenWhisk

[Carlos Santana <cs...@gmail.com>]

This is awesome Dragos +1

I think everybody by now realize that with web actions and having access to
the request and response, there is a lot of modules in ExpressJS that cab
be leverage in OpenWhisk without re-inventing the wheel (web server) :-)

Don't know if you saw last post from Lionel [1] uses a webaction to wrap an
existing express app, my proxying the request and response.
I think he publish some initial work on npm [2] and github [3]

I think he is planning on part 2 of the article to include authentication

You work is very interesting to the point of creating an action that can be
shared as standard middleware in OpenWhisk apps, in terms of composition, I
think it feats very well in a sequence composition were this action will be
the gatekeeper to handle the auth and get the user token which outputs to
the next action which doesn't have to be a webaction it can be a
traditional action.

The output of the traditional action, would then be pass to an action that
knows how to build the http response (i.e. statusCode, headers, body), as
you can see there can be action in the center of the sequence that never
new they were in the middle of a request/response flow.

Rodric coined the term "webify" an traditional action, where thissequence
action can be created with an Action, as you can see we like to eat our dog
food a lot META !!

I think there is a need for both a library and a package that offers this
helper functions, that people don't have to re-invent just to make web
actions handle expressjs middleware.

In terms of delivering this package in openwhisk-catalog repo, I think I
want to go in opposite direction right now it's a big monolithic repo that
I want to break out into individual repositories.

So I proposed having a repository named something like
 "openwhisk-express", we can put the npm libraries/modules and re-usable
actions in this repository and deploy them to openwhisk by default as part
of postdeploy step that today we only deploy catalog packages, but we
should also deploy the other packages in OpenWhisk like alarms, kafka, etc..

Having in it's repo also makes it easy to deploy it with wskdeploy in case
you have your own copy or different version of the package

One minor comment on your README that I didn't follow, we currently don't
have passport installed in nodejs6action runtime, to use your repo as is
today I need to create a zip first, can't use the .js as your doc show
right?

[1]
https://medium.com/openwhisk/deploying-express-js-apps-to-openwhisk-part-1-9133ba5f262c
[2] https://www.npmjs.com/package/openwhisk-expressjs
[3] https://github.com/lionelvillard/openwhisk-expressjs


--Carlos


On Mon, May 8, 2017 at 11:30 AM James Thomas <jt...@gmail.com> wrote:

> This looks amazing! Great work - will have to try it out.
>
> On 7 May 2017 at 23:03, Dascalita Dragos <dd...@gmail.com> 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
>

Re: PassportJS with OpenWhisk

[James Thomas <jt...@gmail.com>]

This looks amazing! Great work - will have to try it out.

On 7 May 2017 at 23:03, Dascalita Dragos <dd...@gmail.com> 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