M2M Auth0 Fallback Service

Hi @channel,

@tools-infra team wants to introduce auth0 fallback mechanism. It handles edge case when the auth0 is unavailable for the client side to do the auth.

The way it is doing the fallback is wrapped by the client library maintained by @tool-infra team, so it is transparent to the client. However, in order for server/api side (our services owned by data-team) to be able to validate the jwt token from the fallback service, since our public APIs already use Istio to do the validation, all you need to do is:
- add new origins spec in infra.servicePolicy.origins field in your helm chart values.
Example: consider this existing configuration on CDP’s dark-spider:

origins:
- jwt:
    audiences:
    - https://tvlk/data/cdp/dark-spider
    issuer: https://tvlk-dev.auth0.com/
    jwksUri: https://tvlk-dev.auth0.com/.well-known/jwks.json

All you need to do is: add the new jwt with the same audiences on existing one, but different issuer and jwksUri :

origins:
- jwt:
    audiences:
    - https://tvlk/data/cdp/dark-spider
    issuer: https://tvlk-dev.auth0.com/
    jwksUri: https://tvlk-dev.auth0.com/.well-known/jwks.json

- jwt: #2: fallback
    audiences:
    - https://tvlk/data/cdp/dark-spider
    issuer: https://athbck-m2m.ath.staging-traveloka.com
    jwksUri: https://athbck-m2m.ath.staging-traveloka.com/.well-known/jwks.json

Notes:

all configuration on Auth0 is copied to the fallback service daily. The configuration are such as: your Auth0 API, Auth0 Applications, the api permission/scope being granted to the application, etc

How To Test in Staging

Once you have deployed above modified configuration in staging env:

wait for a few seconds (~10 seconds) until the configuration being applied to all pods.
you can test hit your public API with jwt token generated by Fallback Service with this url: https://athbck-m2m.ath.staging-traveloka.com/oauth/token . So with auth0, you generate token like this:

curl --request POST \
  --url https://tvlk-dev.auth0.com/oauth/token \
  --header 'content-type: application/json' \
  --data '{"client_id":"<client-id>","client_secret":"<client-secret>","audience":"https://tvlk/data/foo/bar","grant_type":"client_credentials"}'

Now with fallback service, just change the --url to https://athbck-m2m.ath.staging-traveloka.com/oauth/token Please reuse the same client_id, client_secret, audience and grant_type from the Auth0 Application, since the fallback is using the same configuration from Auth0.

If you have any question, feel free to approach us:

about fallback service going live timeline -> @tools-infra
about istio --> @agung.pratama

FAQ:

When will this fallback being introduced on staging and production?

Production: there is no exact timeline right now, but for sure after freeze release period.
Staging: @tools-infra is in the middle piloting this fallback service in staging during freeze release period. In order to support this pilot project, they need 1-2 teams from data team API to enable the fallback service validation.

Is the istio configuration backward compatible with existing flow?

Yes, the existing token generated by Auth0 should be successfully validated by Istio to Auth0 issuer. So adding new jwt validation spec in your helm chart won’t break the existing traffic.

References:

Machine to Machine Fallback service design docs