Note: Assumed knowledge of AWS Cognito backend configuration and underlying concepts, mostly it’s just the setup from an application integration perspective that is talked about here.
Recently we have been working on a Django project where a secure and flexible authentication system was required, as most of our existing structure is on AWS we chose Cognito as the backend.
Below are the steps we took to get this working and some insights learned on the way.
Django Warrant
The first attempt was using django_warrant, this is probably going to be the first thing that comes up when you google ‘how to django and cognito’.
Django_warrant works by injecting an authentication backend into django which does some magic that allows your username/password to be submitted and checked against a configured user pool, on success it authenticates you and if required creates a stub django user.
The basics of this were very easy to get working and integrated but had a few issues such as:
- We still see username/password requests and have to send them on.
- By default can only be configured for one user pool.
- Does not support federated identity provider workflows.
- Github project did not seem super active or updated.
Ultimately we chose not to use this module, however inspiration was taken from its source code to do some of the user handling stuff we implemented later on.
Custom authorization_code workflow implementation
This involves using the cognito hosted login form, which does both user pool and connected identity provider authentication (O365/Azure, Google, Facebook, Amazon) .
The form can be customised with HTML, CSS, images and put behind a custom URL, other aspects of the process and events can be changed and reacted upon using triggers and lambda.
Once you are authenticated in cognito it redirects you back to the page of your choosing (usually your applications login page or custom endpoint) with a set of tokens, using these tokens you then grab the authenticated users details and authenticate them within the context of your app.
The difference between authorization code grant and implicit grant are:
- Implicit grant
- Intended for client side authentication (javascript applications mostly)
- Sends both the id_token (JWT) and acccess_token in the redirect response
- Sends the tokens with an #anchor before them so it is not seen by the web server
- https://your-app/login#id_token=n&auth_token=n
- Authorization code grant
- Intended for server side authentication
- Sends a authorization code in the redirect response
- Sends this as a normal GET parameter
- https://your-app/login?code=n
- Your application holds a preconfigured secret
- Code + secret get turned into id_token token and access_token via oauth2/token endpoint
We chose to use the authorization code grant workflow, it takes a bit more effort to setup but is generally more secure and alleviates any hacky javascript shenanigans that would be needed to get implicit grant working with a django server based backend.
After these steps you can use boto3 or helpers to turn those tokens into a set of attributes (email, name, other custom attributes) kept by cognito. Then you simply hook this up to your internal user/session logic by matching them with your chosen attributes like email, username etc.
I was unable to find any specific library support to handle some aspects of this, like the token handling in python or the django integration so i have included some code which may be useful.
Code
This can be integrated into a view to get the user details from Cognito based on a token, this will be sitting at the redirect URL that cognito returns from.
import warrant
import cslib.aws
def tokenauth(request):
authorization_code = request.GET.get("code")
token_grabber = cslib.aws.CognitoToken(
<client_id>
<client_secret>
<domain>
<redir>
<region>?
)
id_token, access_token = token_grabber.get(authorization_code)
if id_token and access_token:
# This uses warrant (different than django_warrant)
# A helper lib that wraps cognito
# Plain boto3 can do this also.
cognito = warrant.Cognito(
<user_pool_id>
<client_id>
id_token=id_token,
access_token=access_token,
)
# Their lib is a bit broken, because we dont supply a username it wont
# build a legit user object for us, so we reach into the cookie jar....
# {'given_name': 'Joe', 'family_name': 'Smith', 'email': 'joe@jtwo.solutions'}
data = cognito.get_user()._data
return data
else:
return None
Class that handles the oauth/token2 workflow, this is mysteriously missing from the boto3 library which seems to handle everything else quite well…
from http.client import HTTPSConnection
from base64 import b64encode
import urllib.parse
import json
class CognitoToken(object):
"""
Why you no do this boto3...
"""
def __init__(self, client_id, client_secret, domain, redir, region="ap-southeast-2"):
self.client_id = client_id
self.client_secret = client_secret
self.redir = redir
self.token_endpoint = "{0}.auth.{1}.amazoncognito.com".format(domain, region)
self.token_path = "/oauth2/token"
def get(self, authorization_code):
headers = {
"Authorization" : "Basic {0}".format(self._encode_auth()),
"Content-type": "application/x-www-form-urlencoded",
}
query = urllib.parse.urlencode({
"grant_type" : "authorization_code",
"client_id" : self.client_id,
"code" : authorization_code,
"redirect_uri" : self.redir,
}
)
con = HTTPSConnection(self.token_endpoint)
con.request("POST", self.token_path, body=query, headers=headers)
response = con.getresponse()
if response.status == 200:
respdata = str(response.read().decode('utf-8'))
data = json.loads(respdata)
return (data["id_token"], data["access_token"])
return None, None
def _encode_auth(self):
# Auth is a base64 encoded client_id:secret
string = "{0}:{1}".format(self.client_id, self.client_secret)
return b64encode(bytes(string, "utf-8")).decode("ascii")
Further reading
