When I was first learning OAuth, I found that all the guides were text-heavy and lacked code. I personally learn better from code, so I created a code-first guide. Let me know if you have any feedback!
It's a decent skeleton for a server side client. You might consider showing how a token refresh might work.
There is often a need for public client side implementations as well. Are you planning on making one there? It's mostly the same idea but you do the redirects yourself with CSRF and PKCE.
The following features are currently out of scope:
CommonJS
Can’t be the best if CJS support is not offered. I know everyone’s hot for ESM but the fact of the matter is that there is an endless supply of legacy projects that will never migrate to ESM. Deliberately eliminating huge swath of potential users is IMO hostile. Especially because there are tools like tsup that can cross build out of the box.
> PKCE was originally designed to protect the authorization code flow in mobile apps, and was later recommended to be used by single-page apps as well. In later years, it was recognized that its ability to prevent authorization code injection makes it useful for every type of OAuth client, even apps running on a web server that use a client secret.
It's secure as long as you are using a private client (one that can safeguard a client secret), but PKCE costs you nothing to it's strictly better to do it.
at my old company we worked with auth a lot, so it was a requirement for new joiners to watch this in their first week. i still recommend it if you want to learn oauth from 0
I recently started writing an API client for some endpoints protected with Oauth2 and it was an absolute pain at first. Very few examples were available that took into account their quirks, and I ended up relying on a random git repo I found with a working implementation written in PHP.
This was my experience as well. I've previously blindly followed instructions from OAuth libraries, but it frustrated me that I didn't fully understand what was going on.
It's simple with barebones implementations. I'm trying to now learn the server (OAuth provider) side aspect of things so if anyone has any good guides I'd highly appreciate! Alot of the stuff we see in the client side we take for granted e.g redirecting user back to the client? Generating Access tokens? Generating OAuth tokens, verification of identity etc etc.
What I learned from writing my own auth(OAuth as well) something, it's not worth the time and effort. Great learning opportunity, with way too many footguns.
Agreed, I think it's something you should know how to do and then choose not to do it (use an existing library instead). Having a good understanding really helps with debugging issues that come up.
This is really great I learn best from this sort of thing - a bare bones code implementation.
Only suggestions …. add some more providers, some minimal client side code and show how to get some data from the provider api with the token and how to refresh it.
tip_of_the_hat|1 year ago
When I was first learning OAuth, I found that all the guides were text-heavy and lacked code. I personally learn better from code, so I created a code-first guide. Let me know if you have any feedback!
akira2501|1 year ago
There is often a need for public client side implementations as well. Are you planning on making one there? It's mostly the same idea but you do the redirects yourself with CSRF and PKCE.
dpig_|1 year ago
iamcreasy|1 year ago
How much of the process can be pushed to server side? (Sorry, I don't speak JS.)
e1g|1 year ago
Certified, thoroughly tested, zero deps, fully typed, secure defaults, works in Node/Deno/Bun/Edge, supports PKCE/dPoP/etc.
beanjuiceII|1 year ago
moltar|1 year ago
The following features are currently out of scope:
CommonJS
Can’t be the best if CJS support is not offered. I know everyone’s hot for ESM but the fact of the matter is that there is an endless supply of legacy projects that will never migrate to ESM. Deliberately eliminating huge swath of potential users is IMO hostile. Especially because there are tools like tsup that can cross build out of the box.
fulafel|1 year ago
There's advice eg https://www.oauth.com/oauth2-servers/pkce/ that seems to say you should PKCE it even in server-side auth code flow use cases:
> PKCE was originally designed to protect the authorization code flow in mobile apps, and was later recommended to be used by single-page apps as well. In later years, it was recognized that its ability to prevent authorization code injection makes it useful for every type of OAuth client, even apps running on a web server that use a client secret.
YawningAngel|1 year ago
willsmith72|1 year ago
https://www.youtube.com/watch?v=996OiexHze0
sureglymop|1 year ago
a_vanderbilt|1 year ago
tip_of_the_hat|1 year ago
bookmark99|1 year ago
It's simple with barebones implementations. I'm trying to now learn the server (OAuth provider) side aspect of things so if anyone has any good guides I'd highly appreciate! Alot of the stuff we see in the client side we take for granted e.g redirecting user back to the client? Generating Access tokens? Generating OAuth tokens, verification of identity etc etc.
Any help is appreciated!
zipping1549|1 year ago
tip_of_the_hat|1 year ago
andrewstuart|1 year ago
Only suggestions …. add some more providers, some minimal client side code and show how to get some data from the provider api with the token and how to refresh it.
Atotalnoob|1 year ago
jackbauer24|1 year ago
QualmsAplenty|1 year ago