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.
Pretty much all of it! The JS in this walkthrough is all server-side. I tried to keep the JS itself simple so that someone unfamiliar with the language could have an easy time following the code.
In self-certification processes like the OIDC certification program, it's common for developers to certify their own software. This is because the process is designed for developers to evaluate their own implementations against the established standards and requirements set by the certification program.
Self-certification doesn't mean that the process lacks validity or rigor. On the contrary, it involves thorough testing and validation against industry standards to ensure that the software meets the necessary criteria for interoperability, security, and functionality.
If you're curious about the specifics of the process, you can find more information on the OIDC certification FAQ pages. These resources provide detailed explanations of the certification process, the criteria for certification, and the testing procedures involved.
AFAIK there's no "certifying body" that would be able to provide an external "certification".
In any case Filip Skokan has essentially made a career out of building open source OAuth stuff, so even if it's a bit humorous that he certifies his own stuff, it's likely that this implementation is one of the most compliant out there.
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.
All target runtimes of oauth4webapi natively support ESM. Furthermore, experimental "require(esm)" is coming with Node.js 22 in the coming days, giving library authors such as myself even less of a need to bother with CJS targets, publishing, dual CJS/ESM hassles and more. See https://joyeecheung.github.io/blog/2024/03/18/require-esm-in...
> 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.
Hey HN, author here.
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.
Yup, planning on expanding to add a PKCE and OIDC walkthroughs as well!
I really enjoyed the way you presented that, really helped me to focus while reading.
This looks great! I'll surely come back to it later.
How much of the process can be pushed to server side? (Sorry, I don't speak JS.)
Pretty much all of it! The JS in this walkthrough is all server-side. I tried to keep the JS itself simple so that someone unfamiliar with the language could have an easy time following the code.
It’s all server side. It’s written using express which is a web server framework built on top of nodejs
For those looking for production-level OAuth libs, the best implementation for all JS runtimes is https://github.com/panva/oauth4webapi
Certified, thoroughly tested, zero deps, fully typed, secure defaults, works in Node/Deno/Bun/Edge, supports PKCE/dPoP/etc.
Certified by the person who wrote the library? I guess I also certify it
In self-certification processes like the OIDC certification program, it's common for developers to certify their own software. This is because the process is designed for developers to evaluate their own implementations against the established standards and requirements set by the certification program.
Self-certification doesn't mean that the process lacks validity or rigor. On the contrary, it involves thorough testing and validation against industry standards to ensure that the software meets the necessary criteria for interoperability, security, and functionality.
If you're curious about the specifics of the process, you can find more information on the OIDC certification FAQ pages. These resources provide detailed explanations of the certification process, the criteria for certification, and the testing procedures involved.
AFAIK there's no "certifying body" that would be able to provide an external "certification".
In any case Filip Skokan has essentially made a career out of building open source OAuth stuff, so even if it's a bit humorous that he certifies his own stuff, it's likely that this implementation is one of the most compliant out there.
certified by OpenID foundation: https://openid.net/wp-content/uploads/2024/01/oidcc-client-b...
I'll certify your certification!
Out of scope
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.
All target runtimes of oauth4webapi natively support ESM. Furthermore, experimental "require(esm)" is coming with Node.js 22 in the coming days, giving library authors such as myself even less of a need to bother with CJS targets, publishing, dual CJS/ESM hassles and more. See https://joyeecheung.github.io/blog/2024/03/18/require-esm-in...
In what cases is this kindof plain auth code flow still considered good enough from security POV?
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.
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
https://www.youtube.com/watch?v=996OiexHze0
This one is very good! I have recommended it countless people at work.
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.
I'm learning OAuth right now and this is great!
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!
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.
I like the website, but it does NOT work in reader mode.
I like this, oauth has a certain threshold, whether this can run in the browser or not
I've moved on to Deno. How about a tutorial with that?