Google Cloud endpoints and service accounts returning :Oauth framework user didn't match oauth token user

Question

Im trying to access a google cloud endpoint from a cmdline using service account similar to

https://code.google.com/p/google-api-python-client/source/browse/samples/service_account/tasks.py

As instructed from the example, I created a clientid + pk12 cert and using them to create the credential with the SignedJwtAsertionCredential call from the oauth2client.client module.

Works as expected when I call my cloud endpoint running on my local devserver however when I call the deployed gae cloud endpoint I get

Oauth framework user didn't match oauth token user.

Seems to be failing on the oauth.get_client_id(scope) call from user_id_token._set_bearer_user_vars().

When I added a traceback on the exception, it looks to be coming from _maybe_raise_exception

E 2014-01-02 10:30:53.926 raise NotAllowedError(error_detail) E 2014-01-02 10:30:53.926 NotAllowedError

Is there a way to resolve this error without changing the app's authentication type? Seems to be not allowing the request due to the domain restriction?

My goal is to call the cloud-endpoint without having a user involved, not sure if i'm the right path using the SignedJwtAsertionCredential call or if possible?

Additional info.

The authentication type of the endpoint is set to "Google App Domain"

The user_required is True on the endpoint method

The access token generated from the SignedJwtAssertCredential is as expected when i use https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=ya29.

The endpoint works as expected from the api explorer and when there is the auth flow involved.

Using the endpoints_proto_datastore library.

Answer 1

From extensive research I have come to the conclusion that implementing OAuth is not a viable authentication method for apps because of the simple fact that it is horrible to implement. After spending countless hours debugging and asking questions on Stackoverflow about a simple Twitter oAuth implementation, all while receiving countless wrong answers(which safely lets me deduce that a large percentage of developers don't know how to use OAuth) I decided to never again use OAUTH.

So I leave you with the words of the great French Emperor Napoleon Bonaparte

"Una retirada a tiempo es una victoria" -Napoleon Bonaparte

which basically means get out while your ahead and dont waste your time with OAUTH!

Additional information

while experiencing my frustrations with OAUTH I ended up doing some research on who actually came up with this headache inducing concept, and it turns out that the creator has quit this project and has actually publicly denounced OAUTH in his blog:

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ interestingly titled the road the hell. So if the creator is not using OAUTH then you definitely shouldn't either. I have started a petition on https://petitions.whitehouse.gov/ to make the use of OAUTH illegal, so if you like you can join the fight and give us a vote, it is currently gaining traction and we appreciate any support, so go ahead and give it a vote.

Answer 2

The issue was due to the "Google Apps" Authentication Type selected for the application. This setting requires all accounts using the users api to be example.com accounts and the service account is obviously not one.

Once we changed the Auth Type to Google accounts, there was no issue with using service account and validating the client_id.