Princewill Emeka

Software engineer.

[Princewill Emeka @princewill_dev_]

@elonmusk @vtchakarova Do you tho'

[Akintola Steve @Akintola_steve]

One wrong diagnosis in your HealthTech app.
One patient data leak.
One failed hospital integration.
And your startup can collapse overnight.
Meanwhile, you’re wondering why almost every smart founder in Nigeria still runs to Fintech.

It’s not because HealthTech is useless.

It’s because in Nigeria, building HealthTech sometimes feels like carrying the problems of an entire broken system on your head.

[Princewill Emeka @princewill_dev_]

@Akintola_steve @Nueltek Make una involve me

Can I be a part of this community?

[Chioma Amadi @Chioma__Amadi]

I learnt this the hard way.

At the start of this year, I set a clear goal for myself to help at least 50 people from my LinkedIn community land remote jobs. Not just by posting opportunities, but through direct referrals, recommendations, and mentorship.

January was… humbling.

I genuinely thought opportunities would just come to me. That because I had visibility, things would naturally align. But nothing really moved. It felt slow, almost discouraging.

Then February came, and I changed my approach.

I stopped waiting, and started giving out the few job opportunities that came my way instead of sitting on them. I reached out to organizations I was already connected to and actively asked about openings for my people. I made a conscious decision to hire from my own community whenever I had the chance, instead of outsourcing.

Basically, I went from passive to intentional, and things started shifting.

The more I talked about what I was doing, the more people paid attention. The more I showed up with proof, the more trust I built. Now, instead of me chasing opportunities, organizations reach out to me asking for recommendations from my community.

That didn’t happen by luck. It happened because I moved.

So far, 11 people from my community have landed remote jobs through this effort. The 12th is currently in progress, and if all goes well, it should be sealed by mid next week.

A moving man will always meet his luck.

[Jaydeep @_jaydeepkarale]

Authentication & Authorization is beautiful. Every concept has a story. You just don't know it yet.

You build an API.

Anyone can call it. Anyone can read the data. Anyone can delete the records.

There is no "who". There is just "anyone".

So you add a password. Now the user proves who they are before they get in. That is Authentication. The oldest problem in computing, solved with a string you type and hope nobody guesses.

Your server checks the password on login and lets the user in. But HTTP has no memory. Every request arrives like a stranger. The server forgets them immediately.

So you create a Session. The server remembers the user server-side and hands them a Session ID. They send it back with every request. The server looks it up and recognises them.

One stable ID. One server-side store. It works until you have ten servers and no idea which one holds the session.

So you put Session state in Redis. Every server reads from the same store. The user can hit any server. The session survives.

Now you have mobile apps, microservices, third-party integrations. They cannot use cookies. They need something they can carry themselves.

So you use a JWT. A self-contained token with the user's identity baked in. No database lookup. The server verifies the signature and trusts the claims.

It scales. It is stateless. It feels elegant.

Then a user gets compromised. You want to invalidate their token. But the token is valid for 24 hours and there is no registry to check. You cannot un-issue a JWT. It is just out there, valid, until it expires.

So you make tokens short-lived. 15 minutes. You add a Refresh Token, long-lived and stored securely, used only to get a new access token.

Now revocation is possible. The refresh token hits your server. Your server can reject it. The 15-minute window is acceptable risk.

Your app needs to access the user's Google Calendar. You ask them for their Google password. They give it to you. You store it. Now you hold credentials you were never supposed to have.

So you use OAuth 2.0. Google asks the user directly. The user says yes. Google gives your app a scoped token. Your app never sees the password. The user can revoke access without changing their password.

Delegation, not impersonation. The right model.
You add OAuth. Users log in with Google. But now you need to know who they are, not just that they have access. The access token lets you call Google APIs. It does not tell you the user's name.

So you add OpenID Connect. An identity layer on top of OAuth. Google sends an ID Token, a signed JWT with the user's name, email, and a unique ID. Authentication and Authorization in one handshake.
Users are in. Now the question changes.

Not "who are you" but "what can you do".
You give every user full access. It is simpler. One user deletes the production database. Accidentally. They had no reason to have that permission. You had no reason to give it.

So you add Roles. Admin. Editor. Viewer. Each role has specific permissions. Each user gets a role. The Editor cannot delete. The Viewer cannot edit.

It works until you have 40 roles and nobody can explain what each one does.

So you write Policies. Not roles assigned to users but rules evaluated at request time. This user, this resource, this action, this time of day. OPA evaluates it. You get a decision. Access or deny.

Expressible. Auditable. Composable.

A user logs in with just a password. An attacker gets the password from a breach database. Your database was not the one that leaked. Your users reuse passwords. The attacker is in.

So you add MFA. A second factor the attacker does not have. A TOTP code from an authenticator app. A hardware key. A biometric. The password alone is no longer enough.

The attacker has the password. They still cannot get in.
A user gets a phishing email. A fake login page, pixel-perfect. They type their password and their TOTP code. The attacker relays both in real time. MFA did not save them. The fake site looked real. The user could not tell the difference.

So you use Passkeys. No password to steal. No code to intercept. The user's device holds a private key bound to your site's exact origin. A fake site is a different origin.

The key does not work there.

Phishing becomes structurally impossible. Not harder. Impossible.

Your services talk to each other inside the cluster. Service A calls Service B. But B has no way to know the request actually came from A and not from something that found a way inside the network.

You trusted the network. The network is not enough.
So you use mTLS. Both sides present certificates. Both sides verify each other. A service cannot lie about its identity. A compromised pod cannot impersonate a trusted service.

Zero Trust. Not because it sounds good in a pitch deck. Because the alternative is assuming your internal network is safe. It is not.

Authentication answers: who are you.
Authorization answers: what can you do.

Most teams get Authentication right and treat Authorization as an afterthought.

That is where breaches live. Not at the login page. In what you let authenticated users do after they are inside. The pattern across all of it is the same.

Every concept exists because the previous one had a gap. Sessions because HTTP is stateless. JWT because sessions do not scale. OAuth because passwords should not be shared. Passkeys because passwords should not exist.

Each one is a better answer to the same question.

"Who are you. And what are you allowed to do here."

[Princewill Emeka @princewill_dev_]

@ObinnaUkwueze Thanks.

I've always had this in mind, how to reach prospects are always the problem.

[Princewill Emeka @princewill_dev_]

@ObinnaUkwueze How to get to them

[Princewill Emeka @princewill_dev_]

@remote_jobs_hub I'm interested @remote_jobs_hub

Check out my portfolio
https://t.co/PiJyZcmrpd

[Princewill Emeka @princewill_dev_]

@arjunstwtx @fidexcode Okay then

Mutuals?

[Princewill Emeka @princewill_dev_]

@juiceboy_of_abj Did you uninstall your terminals too?

[Princewill Emeka @princewill_dev_]

@SKIDDOWNDR @JenomSenju Mad man😂😂

[Princewill Emeka @princewill_dev_]

@webdeveloper_NG Quick recovery

[Princewill Emeka @princewill_dev_]

@fidexcode ImageVault😂

Used Pixabay's API to search the web and return images based on search keywords.

I remember using 3 days to solve modulus maths trying to get an algorithm to display images in the right grid

I felt like a god man, still laugh at that shii till today😂

[Princewill Emeka @princewill_dev_]

@fidexcode ImageVault😂

Used Pixabay's API to search the web and return images based on search keywords.

I remember using 3 days to solve modulus maths trying to get an algorithm to display images in the right grid

I felt like a god man, still laugh at that shii till today😂

[Princewill Emeka @princewill_dev_]

@arjunstwtx @fidexcode Currently building something similar to this.

How'd it go for you
Any chance it's still live?

[Princewill Emeka @princewill_dev_]

@Akintola_steve Mind of a great founder!

[Princewill Emeka @princewill_dev_]

@smartnakamoura undefined = a variable exists but has no value assigned yet - it's "empty by default"
null = a variable exists and has been intentionally set to "nothing" - it's "empty on purpose"

[Princewill Emeka @princewill_dev_]

Funny how I had dedicated this new week to researching these auth libraries docs to find out one I can start using.

One thing I discovered tho', these libraries are mostly frontend. I loved and had previously always built my auth service layer at the backend level.

So my question, is there any diff or upside to handling auth on the frontend?

[Princewill Emeka @princewill_dev_]

Funny how I had dedicated this new week to researching these auth libraries docs to find out one I can start using.

One thing I discovered tho', these libraries are mostly frontend. I loved and had previously always built my auth service layer at the backend level.

So my question, is there any diff or upside to handling auth on the frontend?