I am myself in the IDP business, was trying to understand the pain points of the user. Even though I am not big fan of AWS but I find that the concerns are baked into the hope that using an IDP would some how make is very easy
> Flexibility of doing local development while on plane
Really depends what you are expecting from the IDP but personally this is one off situation and in most cases its not worth solving. We are in such a interconnected or dependent state where local development without internet is really hard.
> Configuration issue
The features of a solution are two edged sword, it provides people options to tailor it for their own use case and yet at the same time it adds to the learning curve. Good default might have been useful here, however it looks like Author only wanted email and nothing else so it was a departure from defaults
> UI customization
A lot of providers allow some flexibility with the UI but not a whole lot. And then some allow you to host on your website and call the API's for the authentication flows using SDK. Personally this one is tricky, its a UX vs security topic. As a thumb rule never trust the client. The request headers and ability to interact with browsers are what provides you with relatively better state and session control. As an IDP provider I do not want to loose that and still be on the hook for security.
ok so why NOT allow extreme ui customization since client is untrusted anyway? i dont get it. theres no security concern (within this ui) bc the whole thing is untrusted.
I used to hate the AWS docs, now I use Azure and I hate that so much more. At least AWS had loads of (bad) docs that you could string together to figure out how to do something. With Azure, there's just no docs (except for bad videos), and they literally tell you (at the top of every page) that you can do this with AI (I know I can do it with AI, but I'd prefer if I could read your docs to make sure the machine isn't doing something dumb).
My expectation is that I'll end up on GCP in a few years, and that will be bad in hilariously different ways.
There are two ways to do everything; one is deprecated and the other is not yet feature complete.
Glad to know that they're allowing their customers a taste of what it's like to work at Google.
The biggest issue is that it's taken Google a long time to figure out what enterprise security is - it's not something what was in their DNA - and the product shows it. They're too focused on weird fancy half-assed "beyond" solutions to properly implement the basics. They dangle clever federated etc. solutions that only work in some circumstances so that you're better off just avoiding them, but the more basic alternatives are limited in their own way because they focus too much on the fancier solutions.
We were at war with them, so the team was capturing the documentation and timestamping it. They gaslit us to run the clock so the product would slide outside of mainstream support.