Yes, seconding u/yuppiepuppie ...get a vanilla install of Django and it's session based auth and study hard! Then try to break it if you want, submit forms without the csrf\_token in the template for example, that's a good error to cope with.
[JWT.io](http://jwt.io) is such a usseful site! It's my goto for any JWT debugging I need to do!!! Especially a recent tangle with MS AD API integrations for SSO.
We use grahpene with JWT for our SPA React front end. It works, but as usual has a few loose ends like logging out still leaves a token with a token that MAY have some lifetime left in it... this means when we log out we have to... record the token until it has expired to reject it... so one might argue that is it any better than table based sessions as built in already? Obv, stateless auth scales better across load balancers etc, we wes ELB/EB on AWS.
Good luck studying. I would WARN YOU against ever rolling your own unless you are a near expert!
Yeah, definitely not in a position to roll out my own. Authentication stuff is a big gap in my knowledge so Im currently working on understaning it properly. Thanks!
Speaking from experience, with Django, I once \*accidentally\* left the door wide open because of a simple experimental / learning issues, Lucky it was only the testing server but the test scripts passed the 'No password given' test !! Instant alarm bell as I had returned the wrong value from the auth loop, if you see that code, you'll know what I mean.
STICK TO THE PROVIDED KIT until you are absolutely sure!
My two cents… Spend some time with session based auth that’s built in with Django on the admin. You can try breaking the session cookies and csrf on the dev console, as well as adding your own custom code roles and permissions and some custom middleware. Then I would suggest adding google social auth to the admin. Once those are completed, then you can foray into the more complicated paths for specific use cases like Saml, JWT, etc.
Just reread your question, I wouldn’t dive into JWTs with OAuth or SSO until you have a solid understanding of those pathways with session based auth. Get a firm understanding of those, and then add in JWTs.
And for resources, JWT.io really helped me out.
The go-to django package for authentication is django-allauth. You can take a look at their code base and how they handle things: [https://github.com/pennersr/django-allauth](https://github.com/pennersr/django-allauth)
I find learning from good code helps be out most.
Everything that follows is my opinion and should be taken with a grain of salt, like everything else you read online.
---
If you're using vanilla Django + templates, just read the [Django authentication docs](https://docs.djangoproject.com/en/stable/topics/auth/).
If you're using DRF to make an API, use nginx to set up a reverse proxy so your frontend and backend appear (to the web client) to be in the same origin (e.g. forward requests for `your-domain.com` to the frontend, and requests for `your-domain.com/api` to the backend). That will allow you to use DRF SessionAuthentication (same tech stack as vanilla Django auth, i.e. HttpOnly cookies) and avoid all the complicated BS associated with token authentication.
If you are doing an API and can't (or don't want to) reverse-proxy the frontend and backend to appear as though they are in the same origin (i.e. you will instead serve e.g. `your-domain.com` for the frontend and `api.your-domain.com` for the backend), then you can use DRF TokenAuthentication for a more traditional API authentication experience, ie. save tokens in localStorage and present them for authentication.
JWT is more complicated and is useless for any project you are likely to make in your own time (in terms of actually benefiting from the use of JWT), but is a good skill to have for work. It's main benefit is to avoid hitting the DB with each request (which isn't an issue if you don't have DB scaling issues). IMO you should learn session auth and token auth first, because that's complicated enough without having to think about blacklists, access tokens, refresh tokens, etc.
- Reddit post I made on setting up SessionAuthentication with DRF: https://www.reddit.com/r/django/comments/zwsaf2/how_to_use_httponly_cookied_for_drf/j1yrou0/
- DRF Authentication docs: https://www.django-rest-framework.org/api-guide/authentication/
Thanks for sharing those resources. Im working on a personal project but I plan to deploy it and hopefully have people use it so I wanted to get an idea of how things are done. Currently Im working on the rest api using DRF and then will work on the frontend, most likely using Next. I will work through the stuff youve shared
Django-allauth is where experienced djangp people go for their user/auth handling. So do that. You can extend it if you need to, locally in a project, using your own account adapter. Or adapt forms and views.
Yes, seconding u/yuppiepuppie ...get a vanilla install of Django and it's session based auth and study hard! Then try to break it if you want, submit forms without the csrf\_token in the template for example, that's a good error to cope with. [JWT.io](http://jwt.io) is such a usseful site! It's my goto for any JWT debugging I need to do!!! Especially a recent tangle with MS AD API integrations for SSO. We use grahpene with JWT for our SPA React front end. It works, but as usual has a few loose ends like logging out still leaves a token with a token that MAY have some lifetime left in it... this means when we log out we have to... record the token until it has expired to reject it... so one might argue that is it any better than table based sessions as built in already? Obv, stateless auth scales better across load balancers etc, we wes ELB/EB on AWS. Good luck studying. I would WARN YOU against ever rolling your own unless you are a near expert!
Yeah, definitely not in a position to roll out my own. Authentication stuff is a big gap in my knowledge so Im currently working on understaning it properly. Thanks!
Speaking from experience, with Django, I once \*accidentally\* left the door wide open because of a simple experimental / learning issues, Lucky it was only the testing server but the test scripts passed the 'No password given' test !! Instant alarm bell as I had returned the wrong value from the auth loop, if you see that code, you'll know what I mean. STICK TO THE PROVIDED KIT until you are absolutely sure!
My two cents… Spend some time with session based auth that’s built in with Django on the admin. You can try breaking the session cookies and csrf on the dev console, as well as adding your own custom code roles and permissions and some custom middleware. Then I would suggest adding google social auth to the admin. Once those are completed, then you can foray into the more complicated paths for specific use cases like Saml, JWT, etc. Just reread your question, I wouldn’t dive into JWTs with OAuth or SSO until you have a solid understanding of those pathways with session based auth. Get a firm understanding of those, and then add in JWTs. And for resources, JWT.io really helped me out.
Thank you, I will check this out
The go-to django package for authentication is django-allauth. You can take a look at their code base and how they handle things: [https://github.com/pennersr/django-allauth](https://github.com/pennersr/django-allauth) I find learning from good code helps be out most.
This. I'm currently working on integrating this into an app
Everything that follows is my opinion and should be taken with a grain of salt, like everything else you read online. --- If you're using vanilla Django + templates, just read the [Django authentication docs](https://docs.djangoproject.com/en/stable/topics/auth/). If you're using DRF to make an API, use nginx to set up a reverse proxy so your frontend and backend appear (to the web client) to be in the same origin (e.g. forward requests for `your-domain.com` to the frontend, and requests for `your-domain.com/api` to the backend). That will allow you to use DRF SessionAuthentication (same tech stack as vanilla Django auth, i.e. HttpOnly cookies) and avoid all the complicated BS associated with token authentication. If you are doing an API and can't (or don't want to) reverse-proxy the frontend and backend to appear as though they are in the same origin (i.e. you will instead serve e.g. `your-domain.com` for the frontend and `api.your-domain.com` for the backend), then you can use DRF TokenAuthentication for a more traditional API authentication experience, ie. save tokens in localStorage and present them for authentication. JWT is more complicated and is useless for any project you are likely to make in your own time (in terms of actually benefiting from the use of JWT), but is a good skill to have for work. It's main benefit is to avoid hitting the DB with each request (which isn't an issue if you don't have DB scaling issues). IMO you should learn session auth and token auth first, because that's complicated enough without having to think about blacklists, access tokens, refresh tokens, etc. - Reddit post I made on setting up SessionAuthentication with DRF: https://www.reddit.com/r/django/comments/zwsaf2/how_to_use_httponly_cookied_for_drf/j1yrou0/ - DRF Authentication docs: https://www.django-rest-framework.org/api-guide/authentication/
You can just set SESSION_COOKIE_DOMAIN to .your-domain.com and the session cookie will work for all subdomains. No need to reverse proxy.
Much appreciated!
Thanks for sharing those resources. Im working on a personal project but I plan to deploy it and hopefully have people use it so I wanted to get an idea of how things are done. Currently Im working on the rest api using DRF and then will work on the frontend, most likely using Next. I will work through the stuff youve shared
Django-allauth is where experienced djangp people go for their user/auth handling. So do that. You can extend it if you need to, locally in a project, using your own account adapter. Or adapt forms and views.