4 ms·

One interesting idea, in the Platform Engineering space (inside companies), is using TUIs to take advantage of credentials that may already be available on the

One interesting idea, in the Platform Engineering space (inside companies), is using TUIs to take advantage of credentials that may already be available on the developer's laptop. If you serve an internal app as a webapp, then you either need for the webapp to have a service user (icky audit logs) or waste lots of time setting up OAuth-style login flows so the webapp can authenticate as the user (and maybe IT doesn't like the idea anyway). Or, you write something that runs on the dev's laptop, and make use of the credentials that are already available locally, easy-peasy. Auth is simple, use the audit mechanisms that are already in place, easy.

maccard 2y ago
> waste lots of time setting up OAuth-style login flows so the webapp can authenticate as the user Being real - if you can’t manage an oauth library in 2024, you probably shouldn’t be deploying these kinds of apps, it’s about 30 lines of code in go, JavaScript or c# , and they’re just the languages I’ve implemented it in.
- solatic 2y ago
  You realize adding the library is like maybe 10% of the work? * Talk to IT and get your library added to SSO. Make sure both staging and prod. * Ensure user deprovisioning works when IT initiates. Prove to IT that the underlying cached tokens no longer work when the user is deprovisioned, even if it's really the upstream system's responsibility * Convince InfoSec that the particular OAuth library you chose is legit and doesn't pose a security risk If you think 90% of implementation isn't getting approvals internally then you clearly don't work for a big company.