Using multiple security definitions to authenticate the same API

1,847 views
Skip to first unread message

anga...@gmail.com

unread,
Aug 4, 2017, 1:53:21 AM8/4/17
to Google Cloud Endpoints
Hi,

I'm using google endpoints (ESP) with kubernetes to deploy my API. The API calls should be authenticated by using either api-key or Auth0. My endpoint definition yaml looks like this: (Only the security definitions part is shown here)

security:
- api_key: []
- auth0_jwk: []

securityDefinitions:
api_key:
type: "apiKey"
name: "key"
in: "query"
auth0_jwk:
authorizationUrl: "xxxxxxxxxx"
flow: "implicit"
type: "oauth2"
x-google-issuer: "xxx"
x-google-jwks_uri: "https://xxxx.auth0.com/.well-known/jwks.json"
x-google-audiences: "xxxxxx"


When I use auth0 provided jwt token to access the API from outside, it works perfectly. But API key based authentication doesn't work. Google ESP always trying to validate the jwt token.


Response:

{
    "code": 16,
    "message": "JWT validation failed: Missing or invalid credentials",
    "details": [
        {
            "@type": "type.googleapis.com/google.rpc.DebugInfo",
            "stackEntries": [],
            "detail": "auth"
        }
    ]
}

What am I missing here? Any help is highly appreciated.

limi...@google.com

unread,
Aug 4, 2017, 4:28:26 PM8/4/17
to Google Cloud Endpoints, anga...@gmail.com
ESP supports "or" between different authentication providers. For example, you can say, use "auth0" or "firebase" as the authentication provider. API key is not considered as an authentication provider. So you cannot say API key or an authentication provider. 

API key can be used with one of the authentication providers. For example, you can have the following configuration, which means that both "api_key" and "auth0_jwks" are required.

security:
- api_key: []
  auth0_jwks: []

If you have another authentication provider "firebase", you can have the following config:

security:
- api_key: []
  auth0_jwks: []
- api_key: []
  firebase: []

If you only want to use API key, you can write:

security:
- api_key: []

If you only want to use auth0 provider, and you do not want to use API key, you can put:

security:
- auth0_jwks: []

Thanks,
Limin

Dan Ciruli

unread,
Aug 4, 2017, 7:35:55 PM8/4/17
to Google Cloud Endpoints, anga...@gmail.com, limi...@google.com
Hi -

Would you mind telling me a little about your use case?

At Google we have APIs that require keys (say, the Maps APIs) and keys that require authentication (say, the Drive API or most Cloud APIs). 

In general, we use Auth for APIs where there is user data/resources involved, and keys when there is no user data involved.

If you'd share, I'd appreciate the insight. (You can reply to this or email me directly, ciruli at google.com).

Thanks!

Dan
Product Manager

Asanka Sanjaya Herath

unread,
Aug 8, 2017, 1:56:43 AM8/8/17
to Dan Ciruli, Google Cloud Endpoints, limi...@google.com
Hi Limin and Dan,

Would you mind telling me a little about your use case?
​​

I have an API which is running on a kubernetes pod deployed in gcloud and exposed to the public. It is secured using Auth0 jwt. Now I have another pod which runs a separate application(Apache Nifi). That second application needs to call the API running on the other pod. But that second application cannot be authenticated via Auth0, since it is a service. So I need to have a secondary authentication method too. That's why I was looking to integrate API key based authentication together with Auth0.

 API key is not considered as an authentication provider.
 
So as far as I understand I cannot use API key based authentication for my use case together with Auth0. I can't remove the Auth0 based auth at the moment. What is the best way to do it then? Appreciate your help.


--
Thanks,

Asanka Sanjaya Herath

Software Engineer | Zone24x7

Dan Ciruli

unread,
Aug 8, 2017, 11:16:45 AM8/8/17
to Asanka Sanjaya Herath, Limin Wang, Google Cloud Endpoints
Ah, interesting. 

I will let Limin weigh in on this, but in general we would recommend service-to-service auth (signing a JWT using a service account) for that. 


Have you investigated that option?

Thanks for taking the time to go into detail on your use case!

DC

--
You received this message because you are subscribed to the Google Groups "Google Cloud Endpoints" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endpoints+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-endpoints/CA%2B559jTF4%2BUgC_o5aO3QnC1tzh3y4mCJXzhY8R9UpHZKyyuj5g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Limin Wang

unread,
Aug 8, 2017, 1:25:34 PM8/8/17
to Dan Ciruli, Asanka Sanjaya Herath, Google Cloud Endpoints
Hi Asanka,

As Dan said, this sounds like a typical service-to-service authentication use case. You can represent the calling application as a service account, and use a JWT either signed by the service account or signed by Google (the "sub" or "azp" claim should be the service account email). You can find more details in the link Dan mentioned above (https://cloud.google.com/endpoints/docs/service-to-service-auth). 

Thanks,
Limin

--
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-endpoints+unsubscri...@googlegroups.com.

Asanka Sanjaya Herath

unread,
Aug 9, 2017, 1:36:44 AM8/9/17
to Limin Wang, Dan Ciruli, Google Cloud Endpoints
Hi Dan and Limin,

Yes, this service-to-service auth seems like the way to go. Thanks for the help of both of you. For the moment I'm going to use the private IP address based communication between the kubernetes pods( By adding another service which bypasses the ESP). But one day I will have to use this service to service auth idealy. So thanks for pointing that out. Again, appreciate your help.
Reply all
Reply to author
Forward
0 new messages