Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What made me understand these things the most, was setting this up just for myself.

For example host your own instance of Zitadel, Authentik or whatever you find most appealing. Tinker a bit around with it. Then use that instance to authenticate yourself somewhere, i.e. another service where you can set up your own oauth provider. Take a look at the API requests, take a look the code of some OAuth implementation, for example in projects like Gitea, Nextcloud.

May not be it for everyone, though I really like learning by doing.



I'd highly recommend this approach as well. What started as a fascination for me turned into owning a suite of authentication capabilities as a technical PM for one of the SaaS vendors.

The problem with auth is that in practice, it's a lot of messy implementations of insufficient specifications requiring customizations/extensions. Reading a good explainer for say, OAuth, is a great thing to do. But won't be sufficient due to the myriad of weird quirks across various apps/vendors implementation of Auth <Approach>. Dealing with those quirks helped me more deeply understand the underlying concepts and the intent of the spec.

The messiness of the space really means that to be successful, developing some deeper intuitions about how everything fits together can be extremely helpful. And to do this, I think that just playing with auth - a lot - is one of the best ways to develop these intuitions.

I personally liked to spin up dirt simple Express.js apps, and then I'd wire up a sparse UI to the auth endpoints for some vendor, doing a barebones implementation of each thing needed to satisfy the auth protocol used. This really cemented the concepts for me and gave me a library of code that I could easily copy and tweak to experiment with something else.

I also read a lot of blog posts, watched a lot of YouTube videos, and went to an Auth conference or two.


That’s how I’ve learned about authentication, and most other things too. I do worry, sometimes, that I’ve missed a big detail that opens my server to a vulnerability of some kind. That’s where education can help.


Keycloak is also worth checking out - I remember it had some good docs and a lot of different flows & features last time I encountered it...


As someone interested on upskilling, can you perhaps expand on what you mean by "tinker"? I hear a lot of devs talking about "learning by doing" but I'm trapped in a tutorial hell.


pick an outcome you wish to achieve, break it down into subtasks, then work on them one by one.

After completing each subtask, review and re-prioritize the task list

As you go along, more tasks will come up that need to be added to the list

Edit: perhaps the hard bit is coming up with a thing to achieve? There are some examples in the other comments, such as setup xxx to auth with yyy


> perhaps the hard bit is coming up with a thing to achieve

it is. I don't need a full 2FA TOTP AD integrated SSO for my personal NextCloud instance.

The only way to understand it outside of a job task is to make it for my personal NC instance with usercount of one


that’s fine! There are also plenty of charities that would benefit from your help. I used to volunteer to do IT work for the red cross.


TL;DR be curious and scrutinize

When you want to learn something, you probably have some kind of goal in mind. Let's use this as an example: you want to learn about Auth, because you need to integrate OAuth in an application.

Sure, you could just read a tutorial that does exactly accomplish your task, and you are "done". The tutorial will probably tell you, call this API endpoint, use this library, do this and that. But now you only know how to implement OAuth in your application, which may be fine, or enough for you.

But with tinkering I mean, that you don't just learn/read about the requirements for your task, but go a bit 'beyond'. For example, you set up an Identity Provider (e.g. Authentik, Zitadel, Keycloak, ...) which is 'out of scope' for your task, but now you are on the other side of the API endpoint, you can play around with the settings, see what might change with the OAuth integration in your application. Treat it like a sandbox, it's not production, you can 'build' anything you like, you now have power over both sides of the application, stuff you would never be able to do, as you are only tasked to integrate that API endpoint in your application, but would never be tasked, to deploy that API, as this is 'not your job'. You'll maybe spot one or two things, which are good to know for your integration, which you would've never seen in a Tutorial. You'll already pick up some terms that will later pop up while debugging your integration.

Your goal may be something completely different from my example, but what I'm trying to say is. If you want to learn something, because you need/want to do $X don't only learn to do $X but also take a peek at what happens end-to-end, be curious, and maybe question why someone in a tutorial says do $A and doesn't even mention $B. You'll never know that $B exists, even if it may be the better solution to do $X in your case.


Just because you want to get a project you’re working on done doesnt mean that a tutorial that gets things working will be the end all be all of your learning of auth. You can always come back after getting the project done and working to play with auth in ways beyond the tutorial taught.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: