Comment by egamirorrim

The idea is that you do this in advance, at a time when you have legitimate access, then you later lose that access.

So say you have a egamirorrim@mydomain.com google account legitimately. You can use an alias like egamirorrim+woopsie@mydomain.com to create a new google account with a verified email address, resulting in "log in with google" google sending an email claim egamirorrim+woopsie@mydomain.com.

Then, later, mydomain.com fires you. You can no longer log in with the real egamirorrim@mydomain.com associated account, as it was disabled by an administrator. However you can still log into the new google account, egamirorrim+woopsie@mydomain.com , since it's not associated with your organization.

The thing is, afaict this then only becomes a problem if the provider is doing authz based exclusively off of the email claim. I've used OIDC in the past and you are not supposed to grant access to resources based on parsing text in email addresses claim!

I can understand why the blog post author found this counterintuitive, but as they note the docs even warn against doing this.

The blog post goes on to make this statement:

> Most of the service providers I tested did not use HD, they used the email claim.

... OK, well what are they "using" it for? Does this trick actually work on any real world services? If so, I would like for them to be named and shamed.

Even if you (erroneously) assume this value is unique and immutable, that alone doesn't necessarily grant access to anything in and of itself.