Feature: Support OAuth2/OIDC and Bearer token

alexellis commented 5 years ago

Expected Behaviour

As a user with a custom OAuth2/OIDC OpenFaaS authentication plugin configured on my gateway, I need to be able to "log in" and invoke the various CLI commands.

Current Behaviour

We can accommodate this in the OpenFaaS portal UI with no additional changes through the use of cookies issued in the OpenFaaS authentication plugin.

The OpenFaaS CLI does not support this workflow

Possible Solution

Update faas-cli login to obtain an id_token via implicit flow/grant-type
Update faas-cli login to store an id_token optionally instead of basic-auth credentials - add a new flag perhaps?
Update the various commands which currently add basic-auth credentials to set a header of Authorization: Bearer {ID_TOKEN}

Test e2e with a test harness like faas-memory or a hacked end-point.

Steps to Reproduce (for bugs)

Configure OAuth2 for the gateway auth module
Run faas-cli login and see data stored in ~/.openfaas/config.yml
Run faas-cli up successfully

alexellis commented 5 years ago

OpenFaaS authentication plugins: https://github.com/openfaas/faas/tree/master/auth

acornies commented 5 years ago

In addition to what is proposed here, could we also include an option to "download credentials" through the UI?

alexellis commented 5 years ago

Hi Andrew, thanks for your suggestion.

That is not something that I'd considered for an MVP.

My questions would be:

What is the workflow there and how does it work with cookie security such as "HttpOnly" where the stored id_token JWT is unavailable to the browser?

Is this a workflow you've seen elsewhere?

Alex

acornies commented 5 years ago

I haven't looked at the gateway implementation closely yet, but knowing what I do about JWT, OAuth2: If the user has been authorized by the 3rd party, and a JWT has been set as a cookie in the browser (HttpOnly, domain restricted), OpenFaaS gateway ~can assume the user is authenticated~ <- (my work w/ OAuth2 was pre-OIDC implementation) with the stateless representation and we can generate a file to download, containing the JWT.

I like JWT because we don't have to maintain state/db of token, user relationships which allows us to use the JWT token in the auth header: Authorization: Bearer {jwt_token} for an API call.

The end response would be the same in the implicit grant flow, having the gateway/server-side deal only with processing JWT tokens.

itsmurugappan commented 5 years ago

Hi Alex, Proposal looks good. My two cents

While running faas-cli login , open up a browser to authenticate against the auth server and redirect to short lived web server where we can collect the token/code and persist in the config file. After that we could do a code to token exchange if needed.
The above flow needs a human to enter the login in the browser. For automation we could use service accounts if supported by the auth server. Like keycloak does here

alexellis commented 5 years ago

@itsmurugappan for point 1) this has been implemented and released. Would be great if you could test it out? Advise me here or on Slack how that goes.

For point 2) we have implemented the "client credentials" workflow, but I'd be interested to see you try this with keycloak's service accounts and potentially submit a patch if required.

https://docs.openfaas.com/reference/cron/#authentication

Alex

openfaas / faas-cli