Tips for Integrating Okta with a Django App

Security is a concern for many companies these days, particularly as the number of applications used in the workplace continues to go up. Question is, what is the best way to ensure security?

A recent client asked to integrate Okta into their Django applications. As one of the top login security applications out there right now, it seemed a good choice for the client; however, integrating it into the Django applications was another story entirely.

While not terribly difficult, there were several holes in the documentation. Knowing these simple tips can save you time when integrating Okta.

Before we get into that, let’s back up and talk a bit more about Okta.

What is Okta?

Okta is a login security platform that can cater to a wide range of business cases and applications. The idea is that with a single set of credentials, you can log into all of your company’s applications with secure multi-factor authentication.

Building in the same kind of security capabilities can be a hassle, so many companies use platforms like Okta to provide the infrastructure and functionality that they are looking for right out of the box. With Okta, company administrators can:

• add, delete or update users of all of their apps from a single dashboard,
• integrate with applications; and
• manage permissions for employees.

We used the Django Okta Auth library and modified it to match the client’s business case.

pip install django-okta-auth

Between the library, Okta documentation, and a number of online blogs, there was plenty of material to get started. But there were definitely some knowledge gaps that would’ve saved us time with integration.

Tips to make integration easier

NO trailing slashes

When you are configuring your app integration in the Okta admin UI, the login and sign-out redirect URLs need to be EXACT. There can be no trailing slashes, as Okta is actually hardcoded to insert those on its own.

Disable HTTPS check

When implementing on a local server, make sure that the HTTPS check is turned off. Here are the complete settings:

OKTA_AUTH = {
    "ORG_URL": "PLACE URL HERE",
    "ISSUER": "PLACE URL HERE",
    "CLIENT_ID": "ID CODE HERE",
    "CLIENT_SECRET": "SECRET CODE HERE",
    "SCOPES": "openid profile email offline_access", # this is the default and can be omitted
    "REDIRECT_URI": "http://localhost:8080/accounts/oauth2/callback",
    "LOGIN_REDIRECT_URL": "http://localhost:8080/demo/", # default
    "CACHE_PREFIX": "okta", # default
    "CACHE_ALIAS": "default", # default
    "PUBLIC_NAMED_URLS": (), # default
    "PUBLIC_URLS": (), # default
    "USE_USERNAME": False, # default
    "DISABLE_HTTPS_CHECK": True, 
}

Let’s look a little closer at what each of these means:

• ORG_URL is your trial/dev account URL that OKTA gives you when you sign up.
• ISSUER is the same ORG_URL but you need to append /oauth2/default after it.
• CLIENT_ID and CLIENT_SECRET is provided to you when you create an app inside Okta for integrating Okta authentication.
• REDIRECT_URI is when you need to accept the callback data from Okta after you put in your credentials on the login page.
• LOGIN_REDIRECT_URL is the URL where you'll be redirected after you get authenticated.
• PUBLIC_NAMED_URLS are the URLs that won't require Okta authentication if you mention them here.
• USE_USERNAME basically accepts username for Okta authentication on your login page if set as True otherwise it'll accept email.
• DISABLE_HTTPS_CHECK is for localhost development and has to be set to True and when deployed locally for development.

That last one is key. Once everything is ready for production, turn the check off and you’re up and running. Read more Django best practices and Django case studies from Six Feet Up.