3 ms·
I'm not quite sure what you're getting at, as OIDC and friends are very standardized when it comes to quite a few of the most important claims you would expect.
by andrewstuart2 3y ago
I'm not quite sure what you're getting at, as OIDC and friends are very standardized when it comes to quite a few of the most important claims you would expect. There's an entire IANA registry [0] devoted to registered claims, in fact.
As for authz choices, you're correct that it's almost always entirely dependent on the application, and subject to frequent change as applications evolve, and as e.g. user and group structure evolves as well. The "managers" group of today might turn into "directors" and "VPs" as the company grows, and "pictures" might soon incorporate "albums" as an optional grouping factor with its own permissions.
In general, I would not really call authentication/authorization boring. There are components of it that are solved, but the reality of today is that people want a "share" link that they can paste in Slack and anybody can use it within seconds, and that kind of speed needs to be accounted for in authz, which is a significant engineering challenge.
Papers like Zanzibar [1] are super interesting to read too. And at least to me, not boring at all.
[0] https://www.iana.org/assignments/jwt/jwt.xhtml https://www.iana.org/assignments/jwt/jwt.xhtml
[1] https://research.google/pubs/pub48190/ https://research.google/pubs/pub48190/
- treve 3y agoYes they are standard, but this is akin to having a 'standard menu' at a restaurant. You're not getting every item on the menu, and for the ones that you do you could make modifications. OAuth2 and OpenID has many standards documents. A 'standard' OAuth2 server can be written in 30 minutes if you only care about 1 grant type and none of the extra features and 1 flavor. But it can also take 6 months if you do want support for all the features such as introspection, revokating, multiple grant types, ID Tokens, etc. I wrote a bit about this issue here: https://evertpot.com/oauth2-usability/ https://evertpot.com/oauth2-usability/ Note that this post is only about OAuth2, adding OpenID to the mix blows this problem up further. The key point is that OAuth2 and OpenID provide a framework for building authentication and identity systems, with a matrix of possible implementation details that often have to be communicated out-of-band. It's still useful as a foundation, but picking an OAuth2 implementation is not as simple as just finding one that is OAuth2 compliant, you might have to dig deep and find out what parts you need and if your server implements them.
- Zetice 3y agoThis is helpful, thanks! By "boring", I see that as a good thing; you want auth to be boring, is my point. Intellectually stimulating it is in any event (I enjoy learning systems), but I want the process to be me learning how it's done (the "boring"), not having to come up with novel solutions given my problem set (the "exciting").
- d0gsg0w00f 3y ago> And at least to me, not boring at all I love Auth! It's always the key that unlocks everything else. Chances are that 50% of the "blocked" problems in your company can be solved if you know how their Auth works. Plus, everyone thinks it's not worth their time to learn so you can be a superhero with just a few weeks of work.