Auth0 API authorization with Google App Engine

Get Help
, , ,
1

tl;dr

What is the best way to decode an API access_token from Auth0 using Google App Engine/python/webapp2 as a backend stack?

I am inexperienced in the ways of authentication, authorization, and cryptography, so please bear with me if I get my nomenclature all mixed up :slight_smile:

I am writing an app for a student project, for which I am creating a REST-ish web API. I would like to use Auth0 for user authentication and API authorization. I am creating the app on Google App Engine (GAE), standard environment, using python and webapp2 as the primary technologies.

I have successfully retrieved an API access_token on the client side, and I am working through the python token verification flow, similar to the one found in the Auth0 python API example. I’m getting stuck at the point of decoding the token, though!

The first problem is that the example uses the python josepackage to decode the token. jose, and also PyJwt, depend on the python cryptography package for their heavy crypto lifting. Unfortunately, GAE standard environment does not support python packages with C libraries, so cryptography is not supported. PyJwt has an alternative setup they show specifically for use with GAE, which relies on pycrypto instead of cryptography. GAE offers pycrypto as a built-in library so that is fine. This works if I want to proceed with PyJwt.

The next problem I have is that the token verification flows I read about for Auth0 use jwks key sets to decode the token. Unfortunately, I cannot figure out how to use PyJwt in legacy mode with a jwkskey … it expects a PEM formatted key.

I can picture several possible solutions, but I don’t know if they exist! Maybe something like one of the following?

  • Convert the jwks key set to a PEM formatted key using pycrypto instead of cryptography?
  • Find a web API to decode the token for me, maybe from Auth0 or jwt.io?
  • Retrieve a PEM formatted key from the Auth0 endpoint instead of a jwks set?
  • Just use HS256 instead of RS256? Would this fix my problem?

Are any of these ideas realistic? Has anyone else had to deal with this issue?

2

Given that the token will be verified by a server-side environment then the use of HS256 would be indeed a suitable alternative that could likely resolve all the other situations without introducing any issue. In general RS256 will be required if the party performing the validation cannot maintain the signing secret secret or if you do not trust it enough because possession of the signing secret would mean that it could both validate and issue tokens while with RS256 it would only be able to validate tokens.

In your position, unless there are requirements for RS256 that you did not mention I would recommend you to consider HS256 because the signing secret for this algorithm is much simpler to manage than the keys associated with RS256.

3

Thanks! I will give this a try.

So if I understand right, for HS256 I will copy the signing secret from my Auth0 API dashboard, keep it stored (somewhere) in my API server code, and use that to decode the token. Does that sound right? What is the best practice for storing the signing secret for a public github project?

Thanks again!

4

Yes, those steps are correct. The general recommendation is that this sort of information should never be included in source control and instead be obtained from some sort of configuration system that is able to automatically pick the right values from the environment. This way you set the secret on the environment/machine where the code runs and the code picks the value transparently depending on the environment in which it’s running.