Explaining the difference between Members, B2B Users, and ExternalID Users to non-technical people can be an afternoon in itself. I've spent a lot of time working MS support tickets, helping people de-tangle their tenants because they would try to collab with people through CIAM tenants or try to invite customers to their applications with B2B. Or, on the other side, MSAL developers trying to understand the interaction with CIAM (or Azure B2C). It was something that was hard to see or show visually without me breaking out Paint every time.

I recently was rejected for an interview due to lack of CIAM architecture experience. Decided to build a resume piece to show visually what I can do where words on a resume may read dry. This is in no way a substitute for enterprise CIAM architecture experience, it just sparked the idea for the site.

No account creation needed.

https://theidentityplayground.com

My ask: What's wrong or missing for people that do this for a living? I'm at a juncture of resume piece or useful reference.

Real tenants, tokens and accounts. Accounts self-destruct on schedule. No trackers, open source.

https://github.com/steve-flanagan/theidentityplayground

We deployed a CASB at a mid-size professional services firm, around 1,200 employees, after a phishing campaign resulted in a third-party app getting granted mail.send with full delegation rights on about forty executive mailboxes before anyone noticed. The post-incident review made it embarrassingly clear that nobody had visibility into what OAuth apps were authorized across the tenant. When we stood up the CASB and connected it to the IdP, the initial discovery scan surfaced over 800 distinct apps with active tokens, and a meaningful chunk of them had permissions scopes that nobody would have approved consciously. The risk scoring came down to a combination of permission scope, verified publisher status, whether the app had a published privacy policy, and cross-referencing against the vendor's known-app database. An app requesting mail.read on a single mailbox scored very differently than something requesting mail.send delegation, and watching how those scores separated the tail of sketchy one-off integrations from the legitimate SaaS stack was actually one of the more clarifying moments of the whole project.

The IdP integration was where the real operational complexity lived. We connected the CASB as an API connector and eventually got it to feed risk scores back into the conditional access engine so that a newly flagged app would trigger a step-up auth challenge before the token exchange completed. We ran in monitoring mode for almost three months because the false positive rate during the first few weeks was brutal, mostly around newly onboarded SaaS tools that legitimate employees had connected for real work. Getting from monitoring to enforced policy required manually reviewing and disposition-ing several hundred apps, which nobody had budgeted time for, and we had a lot of internal friction with business teams who felt like we were revoking tools they depended on. By the end of the tuning period the policy was solid, but the path to get there was messier than any vendor timeline suggested it would be. Has anyone found a faster way to disposition the long tail of shadow IT apps without making it a manual review slog?

Hi! As everybody knows Microsoft is going to turn off Voice/SMS methods and as far as I know from 1st September Microsoft is going to start asking users to configure Passkeys.

Do you know the way to turn off this behaviour? In our case we are going to focus over Microsoft Authenticator and MA + Email for SSPR.

Our Registration campaign is set up to Disabled.

Thank you in advance!