search

apache / openwhisk-apigateway

Apache OpenWhisk API Gateway service for exposing actions as REST interfaces.
https://openwhisk.apache.org/
Apache License 2.0
64 stars 45 forks source link

For the identity propagation, used a signed JWT to carry the credential downstream #130

Open shiup opened 7 years ago

shiup commented 7 years ago

When an endpoint is protected by OAuth, there is a need to propagate information to downstream traffic..

Ideally with a signed JWT, with the following claim.. sub : resource owner tid : transaction id client_id : [optional] application Id/client_id scope : [optional]

mhamann commented 7 years ago

Are you suggesting that the gateway signs a new JWT on behalf of the identity provider?

luzbel commented 7 years ago

Right now, if you need the identity of caller, you must call again token introspection endpoint using "params.__ow_meta_headers.authorization". At least, i don't know any other method. Another problem with this approach is you need to know which provider (google,facebook,github) is configured at api Gateway level, but action should be not aware of this. My action code should be independent of my gateway security conf. Same action code should work for APIs using Github or APIs using Google or using Facebook.

Sign a JWT could be an option. An action could trust api gateways tokens, but if you action propagates this token to others backend endpoints they must verify its properly signed.

Other option is just propagate info returned by the token introspection in other headers (for example, oauth.resource_owner, oauth.scope, etc. but, at the end, you are reinventing JWT as you need to figure it out some way for backends trusts those headers) or make the info available to the action code as some context variable (i don't know if its possible or a good idea). API Connect, for example, put oauth info (resource owner, scope, ...) available to Gateway policies in context variables . Maybe environment variables of the docker container running the action??

mhamann commented 7 years ago

@shiup / @luzbel I think a signed JWT is probably the right way to go. If we sign it asymmetrically, that should enable the downstream server to validate it with a public key.

If we do that, then we just have to figure out how to distribute said key. I think it should just be an endpoint that the gateway provides, which makes for easy retrieval by the downstream.

luzbel commented 7 years ago

In Google, following OpenID, a successful response already includes a JWT that contains identity information about the user that is digitally signed by Google.

Google-issued tokens are signed using one of the certificates found at the URI specified in the jwks_uri field of the discovery document.

Not sure about Facebook and GitHub. Are they OpenID compliance? Now, I'm not sure if it is better to sign a new token or propagate the original one. New token is easier for action developers, propagate is easier for gateway.

mhamann commented 7 years ago

Facebook and GitHub have some nuances, but are generally OIDC compliant.

I think one of the primary goals of this gateway is to improve the developer experience, which is why I think generating a new token is the right way to go.

That said, I also think it's desirable to have access to the original token, so maybe it should be wrapped within the new one or sent along in a separate header (e.g. if I want to call the Google API later on).

taylorking commented 7 years ago

Now that we have JOSE in here it might be cool to sign our own tokens so the backend could verify a request was coming from a gateway.