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

Just to expand a bit on my criticism. It's called a "complete guide to protecting your APIs with OAuth", yet there's no discussion of:

- Authorization server, roll your own, run your own (like Ory Hydra), or use third-party (like Azure AD)?

- Tokes, if you can choose, should you go with opaque tokens, JWT or something else? What about token lifetimes?

- When you get a token from a client, how do you validate that the token is valid?

There's probably more, but I feel at least these points should be included in a "complete guide".

Change the title and it's a fine OAuth blog post. edit: for example, add ", part 1 - introduction".



Thanks for this critique. I have limited ability to edit the post, but will try to answer these here.

> Authorization server, roll your own, run your own (like Ory Hydra), or use third-party (like Azure AD)?

If by 'roll your own' you mean 'use an open source library like Python's OAuthLib', all three of these are valid options. Really hard to give general guidance because it depends on the complexity of your application environment (1 app in rails? 10 apps with mix of custom and COTS?) and operational maturity (do you want to run your own server for compliance or control reasons? do you have the skills to do so?).

> Tokens, if you can choose, should you go with opaque tokens, JWT or something else? What about token lifetimes?

"if you can choose" is an important clause here. Many times it'll be dictated by the Authorization server you choose. All other things being equal I'd lean toward JWTs because of their widespread support, but I know others have other opinions.

Re: token lifetimes, this is something you need to threat model out (what happens if a token is stolen?). Generally recommend seconds to minutes for access tokens and longer lived refresh tokens. Also whether you should use token binding or can live with bearer tokens.

> When you get a token from a client, how do you validate that the token is valid?

That will be discussed in part 2 of this series, but in general you should validate the signature (if it is a signed token, often a JWT) or use introspection to ask the Authorization server if it is valid. Then you should validate the claims.

There is definitely more, but thanks for the feedback!


Thanks for the reply, good stuff. Most of this could go into part 2 I think.

For part two I would definitely want at least some discussion around choice of authorization server. I realize a full deep dive is too much, but at least list the options (use a lib, use your own server, use third-party) with some pros and cons or something like that.

If you do go into token generation and usage, and mention JWT, do mention the requirement to verify the alg field against expected value. Just given the issues it's caused in the past.

Anyway, hope I wasn't being too negative, that wasn't my intention.


Hiya,

No worries, I appreciated the feedback. That's one of the magical parts of HN comments.

Unfortunately part 2 is already edited and ready to go and so won't cover the choice of authorization server; it kinda assumes you are using one.

Here's an HN comment I made that covers the dimensions of what to think about: https://news.ycombinator.com/item?id=26411197

I also have collected a series of essays around what to think about w/r/t outsourcing auth (including what kind of auth server to choose): https://leanpub.com/theultimateguidetooutsourcingyourauth . Here's a coupon for 50% off that book: hn-april . Or you can email me and I'll get you a copy; my contact info is in my profile.

Thank for the feedback about JWTs. My general recommendation is to use a well vetted open source library for the signature verification, which should handle the alg check. But calling it out is a good idea.




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

Search: