Utilize Django authentication as a microservice

Using Django Deployment
1

Hello everyone,
I need suggestions for developing such a complex project. I am following this blog
I have two projects separate projects.

  1. User authentication: can be used as a rest API service. It contains a user database, authentication method.

  2. MainProject → Frontend application: This will utilize the user authentication API.

In frontend application, I created an HTML template (user sign in, signup, refresh token, authenticate token, etc)
When a user registers and logged in (1) will provide me a JWT ticket.
Now to access my protected resources I need this token but how can I use this to the rest of my protected resources in my frontend application as my request has always anonymous users (this part is complex and no idea how to tackle)?

To make it a bit easy I created a local database where I stored the jwt token when a user logged in to the frontend application HTML page.

My question is how to keep track of the logged-in user on my frontend application based on this ticket?

1 Like
2

My very personal opinion is that you’re trying to make a round peg (Django) fit into a square hole (a microservice architecture).

It has never seemed to me that Django is designed for that use-case. Django appears to me to more advertise itself as the “Batteries Included” framework. (The blog you reference, being a dotNet-related article really doesn’t apply here.)

If I were building something like this, the User authentication would just be a minor component - almost an add-on - to the primary application.

You’ll probably want to review Django’s built-in User Authentication System (https://docs.djangoproject.com/en/3.0/topics/auth/) to see how that fits into the pattern you’re describing. In essence, it’s already doing what you need

Now, having said that, the general means of using that type of ticket involves either setting a cookie with the ticket, or appending the token to the URL as a query variable. It’s a common pattern used in many places. This token is going to be sent with every page request, allowing the server to know who that user is. Since it is such a common practice, Django already provides that for you.

Ken

3

Thanks for you suggestion but if we save the jwt token it will lose the stateless property and may become a security issue because we do not want to expose this to the user.
BTW thank you so much.

1 Like
4

I’m sorry, I guess I don’t understand what you’re trying to accomplish.

Unless you’re only going to retrieve one page, you’ve got to do something for the server to know that the request is coming from someone who is already authenticated. (Either that, or they need to supply their password for every page they request - which works out to essentially the same thing.)

Yes, in theory, an exposed token is a potential vector for an attack - that’s why it’s also important that authenticated sessions be conducted through https and not http.

But that’s the way the web works. The browser needs to supply something with every request to identify itself to the server, and usually it’s a cookie.

In a modern web application, “stateless” is not a benefit for any site requiring you to authenticate yourself.

5

Yes, I am following what you talking about. Let me explain in a simple way.

I have a project let say “Hospital”. I want a microarchitecture paradigms in developing this project.

The hospital has more than 10 modules (application). Each application is independently working with there own database as a backend. Maybe there need some coupling with applications.

Within these 10 applications, I have an authentication and authorization application too which is one of the basic and most important parts of my project.

I write REST API for each of my applications. Now, i want a frontend to used all these applications under one umbrella. Each application will be at a different location (server).

So for this purpose, i prefer Django REST Framework as a backend. I also want to develop the frontend in the Django framework.

So let say initially, i need a sing in and sign up template.

  1. A user wants to register -> fill the form -> click register -> call rest API of my authentication app (create a new user)1.

  2. The same user now enters credentials and wants to log in. So again -> call res API of my authentication app (check the user name and password and generate JWT token).

Now I have this token with user identity and expiry date. After login, I will only check the user against this token check the token expiry and give permission, and redirect the user to my home page.

My question is how to keep track of the current user identity based on the token in my frontend application in Django till the user manually logout? Because each time when a user redirects to the next page in Django we just have the request object and the request has an anonymous user.

1 Like
6

Ah, ok, thank you! Now I’ve gotten a much clearer picture of the situation. There appear to be at least three different issues here to address.

(Note: The key item addressing the authentication issue is actually the last item in this list - jump down to the last item if you want to get right to that point)

  1. First, you state “I want a microarchitecture…” I’ll repeat from one of my earlier answers - Django as a framework isn’t the best choice for that architecture. The components are designed to work with each other, not to be split up and used independently. If you’re looking for a more “put the pieces together” type of approach, you may find it easier to use Flask or Bottle - both of which I have used to great success in specific situations.

  2. “I want a front-end to use all these applications”. That implies to me that you’re talking about writing something using a JavaScript framework such as Angular, React, Vue, etc.That’s fine, but you also write “I also want to develop the frontend in the Django framework”.

You’ve got two different objectives here. You’re either going to write pages that are generated by Django and are accessed by the browser directly, or else you’re going to have a front-end application (hopefully using one of the JavaScript frameworks) to access these REST APIs across all the different servers. (Well, you could do some of each, but that seems like an architectural / maintenance nightmare in the making.)

Creating the web pages in Django, while having your Django views call the other Django-based APIs is a perfectly fine approach.
But if you’re going to have Django rendering your web pages, I would strongly suggest that all web access be through one server, and allow the Django views call the REST APIs that reside on the other servers. Don’t bounce the user from server to server just to retrieve individual pages.Since the work in the APIs is being done externally to the views, there’s no reason and no benefit to splitting that function among the separate pages - and in fact will make development significantly harder as this would inhibit your ability to share templates and code among the different pages.

  1. So let’s assume that you’re writing a JavaScript front-end that need to invoke Django REST APIs across multiple servers.(The creation of that front-end really doesn’t have anything to do with Django directly, unless the REST APIs being called are returning rendered HTML blocks to be injected into the page by the JavaScript call.) Now you have the issue that started all this discussion - how to I maintain authentication across multiple services.

That’s where your JWT token comes into play - when you authenticate, you (the browser) receives this token, and then supplies that token with all future requests. The servers, whether they’re REST APIs or standard Django views, can then validate that token.

There appear to be a couple of packages available to assist with this:

The Django REST API integration appears to be straight-forward, the standard Django integration less so.
At a minimum, your standard Django view integration is probably going to need some middleware to accept the token from the browser in the request, and validate it before passing it along to the view.

To get started, see:

I’ve also found a couple of blog posts that may provide some more examples and give you more ideas as to how you might want to address this:

Note: I have not tried any of the code examples contained within these posts - I can’t vouch for them being complete or correct. However, I have read through them enough to see that they appear to cover all the key points - at least in enough detail to help you get started.

Ken

1 Like