oauth2 frontend authentication with Okta


I’m in the process of implementing an authentication system similar to what is described here.

My front end is React and I’ll be using DRF on the backend.

I’ve done some purely front end testing of a login/logout flow using the okta-react and okta-auth-js node libraries and it all seems to work fine.

However when I start implementing Django on the back end it breaks at the redirect request because it wants to handle the call to oidc/callback and subsequently throws a Page Not Found error.

Is there a proper way to keep Django out of the authentication process and leave that totally up to the frontend?

Any implementation examples would be greatly appreciated!

What exactly do you mean by this?

The back end can never never trust the front end. Why? Because the server has no control over the front end. Security of your site must rely upon the server playing its part in the authentication cycle. There always needs to be some direct communication between the server and the authentication provider to validate that authentication.

per the linked article:

As far as I understand it, authentication on the frontend is used to secure the routes and provides an access token for validation when calls are made to the backend.

However I’m still new to all of this so perhaps I’m mistaken. I thought I could retrieve the access token purely on the frontend and then use that for subsequent REST call authentication whenever I need to retrieve data from the server.

If that’s a valid workflow then there’s no reason to involve the server in the initial retrieval of the access token, correct?

In the end I just want something that works and is secure. I’m rather confused by the options. Should it be purely front end, should it be purely backend, maybe a hybrid of the two? I’m not sure what the best approach is.

The very last block of that diagram still shows the backend contacting the OAuth2 provider to validate an access token. Superficially, it looks like they’re just moving the need to manage that connection from early in the process to late in the process. I’m not sure I see where there’s a lot of benefit from this.

Also from the text above that diagram:

It somewhat increases the risk from a compromised client, but it works well, in general.

That doesn’t inspire a lot of confidence in me regarding the security and reliability of this process.

From a security perspective, the actual process of Authentication always occurs in the back end.

Keep in mind what’s logically happening here.

  • The client is authenticating through some service.
  • The client, somewhere in the process, needs to pass a token to a different server.
  • That other server then needs to validate the token with the original authentication service.

Sure, you can sequence this process in different ways, but the fundamentals remain the same.
You can’t change where these steps occur without fundamentally affecting the security of this process.