4 ms·

Thank you for the comment! I have to admit it's hard for me to follow what you're saying, I'm not sure what you mean by "innovation" or "middle ground", or wher

Thank you for the comment! I have to admit it's hard for me to follow what you're saying, I'm not sure what you mean by "innovation" or "middle ground", or where you're getting that the JWT structure (of an OIDC token?) isn't consistent.

Zetice 3y ago
As a startup, I very much do not want to innovate or be in any way "creative" when implementing functionality that isn't my company's core value prop for customers. So for something like AuthZ I want to be as conforming as possible to what "everyone else" is doing, and I want to do that as quickly and seamlessly as I can, so when I say "innovation" here, I'm saying I don't want to build a new library or write a new technology to do AuthN/Z that isn't well-trod ground. What I've experienced however, is that this isn't as easy as I expected. The "middle ground" here is between "inventing form whole cloth a bespoke library to solve AuthZ" and "do absolutely nothing whatsoever new". Using CASL in my infra's middleware to solve AuthN seems to be working for me. I can write the rules in a way CASL understands, and I was able to quickly implement the middleware without having to do anything crazy. As for "JWT structure being inconsistent" I mean to say that often I'm asked to "connect" many different providers, e.g. Google social sign-in, Okta, Auth0, etc., all of whom have their own way of structuring their JWT payloads (beyond the standard that is), and using Cognito as an intermediary has been helpful to avoid all of that, as again, I'm trying to do as little as possible myself.
- nathan-wailes 3y ago
  Thank you for the clarification and for the tip about CASL and Cognito!
- prpl 3y ago
  Maybe it's worthwhile pointing out that even Auth0 is kind of exploring a bespoke way of doing this: https://auth0.com/docs/customize/extensions/authorization-extension/use-rules-with-the-authorization-extension https://auth0.com/docs/customize/extensions/authorization-ex...

Zetice 3y ago

As a startup, I very much do not want to innovate or be in any way "creative" when implementing functionality that isn't my company's core value prop for customers. So for something like AuthZ I want to be as conforming as possible to what "everyone else" is doing, and I want to do that as quickly and seamlessly as I can, so when I say "innovation" here, I'm saying I don't want to build a new library or write a new technology to do AuthN/Z that isn't well-trod ground. What I've experienced however, is that this isn't as easy as I expected. The "middle ground" here is between "inventing form whole cloth a bespoke library to solve AuthZ" and "do absolutely nothing whatsoever new". Using CASL in my infra's middleware to solve AuthN seems to be working for me. I can write the rules in a way CASL understands, and I was able to quickly implement the middleware without having to do anything crazy. As for "JWT structure being inconsistent" I mean to say that often I'm asked to "connect" many different providers, e.g. Google social sign-in, Okta, Auth0, etc., all of whom have their own way of structuring their JWT payloads (beyond the standard that is), and using Cognito as an intermediary has been helpful to avoid all of that, as again, I'm trying to do as little as possible myself.

nathan-wailes 3y ago
Thank you for the clarification and for the tip about CASL and Cognito!
prpl 3y ago
Maybe it's worthwhile pointing out that even Auth0 is kind of exploring a bespoke way of doing this: https://auth0.com/docs/customize/extensions/authorization-extension/use-rules-with-the-authorization-extension https://auth0.com/docs/customize/extensions/authorization-ex...