Comment by danudey

Comment by danudey 4 days ago

62 replies

View on Hacker News

Well, think about it this way:

1. I create DankStartup and my company uses Google workspaces and Google auth for a bunch of stuff, like payroll.

2. DankStartup goes under and we close our Google accounts/let our domain lapse.

3. Someone else buys DankStartup.com, sets up a Google workspace, and attempts Google auth to log into stuff, and it works.

The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y".

Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are therefore the same people as far as they're concerned and is asserting that to other companies. They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people, so those other companies aren't even capable of doing their due diligence of extra validation if they want to.

It's similar to looking at a driver's license and just matching the name rather than the actual ID number; it's possible for someone else to have the same name as you, and identity documents have unique identifiers for specifically that reason.

stackghost 4 days ago

>Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are therefore the same people as far as they're concerned and is asserting that to other companies.

Yep I understand the mechanism by which this gets abused; I think we just disagree on the implications. I don't work for Google but it seems from the outside that they're treating the OIDC subject claim as referencing the domain attached to the workspace account, or something similar. I've seen implementations where the `sub` claim is more granular, so to me that indicates the field is underspecified.

Given all that, I suppose TFAuthor's proposed solution is a good way forward.

I still think classifying this as an OAuth vulnerability isn't correct.

Reply View 9 replies
  • johnmaguire 4 days ago

    Traditionally, SAML / OIDC trust is established using public/private keypairs. Each IdP/SP pair gets a unique combination. In this case, a domain changing hands would not allow the new owner to gain access to the old owner's accounts.

    In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. See the distinction between "public and internal applications" here: https://support.google.com/cloud/answer/6158849?hl=en#zippy=...

    Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts. A common misconfiguration here is to use the domain portion of the "email" attribute - this can be spoofed by Google Workspace admins. That's not what's happening here.

    Instead, Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes. This field cannot be overridden by Google Workspace admins. The trust breaks down when the domain changes hands, a new Google Workspace account is opened, but the old "hd" value is reused.

    You can read more about "hd" here: https://developers.google.com/identity/openid-connect/openid... (find the table and read the descriptions for both "email" and "hd".)

    You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP (be very careful you mark it internal!) A new domain owner would not be able to retrieve the secret key you previously generated.

    Reply View 8 replies
    • anon84873628 4 days ago

      To clarify, any multi-tenant app that has a Google login button that "just works" without you having to set up your own OAuth client creds is using the "public" app option. Effectively the OAuth client side doesn't care whether you use a public Gmail account or enterprise Workspaces account to login.

      However, on the Workspace Admin side you can set policies as to whether the org accounts can login to arbitrary public apps by default, or set up an app allowlist, etc. It's definitely a best practice not to let your users login to arbitrary apps, even if it's only for the profile data and not other API scopes.

      If you do login to a public app with an org account, how that app decides to group/authorize users from (what it perceived as) the same org/domain could be a sensitive procedure with opportunity for exploit, and it seems like maybe Google should offer a more reliable unique org id claim.

      If you are making your own internal app then client is going to be internal only by default. Note this is managed in a GCP project. If you're using Workspace and GCP then you may want to use GCP services with built-in Google auth like Cloud Functions, App Engine, Identity Aware Proxy, etc.

      Reply View 0 replies
    • delfinom 4 days ago

      Yea "hd" doesn't work here.

      Users can make google accounts with corporate domains but without gsuite hosting attached. The same concern applies to just @gmail.com addys. Google has gotten big on nuking inactive accounts now, what stops similar openings where a person's inactive account gets recreated by an attacker and waltz his way into SSO systems? There's some corporate systems (usually benefits) that allow personal emails attached to the same account as work emails for example.

      I imagine the fact the author is writing that Google reopened the bug and is issuing a bounty means there are Google engineers more than aware of the issue rather than trying to argue what Google does and does not intend.

      Reply View 1 reply
      • the-rc 4 days ago

        Once a Gmail account is deleted, it can't be recreated by anyone, including the original owner.

        Reply View 0 replies
    • [removed] 4 days ago
      [deleted]
      Reply View 0 replies
    • nodamage 2 days ago

      > In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application.

      There are plenty of use cases where this is appropriate. If you wanted to allow users to login to Hacker News with their Google accounts you would use this option because you do not care what workspace they belong to.

      > Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts.

      This is a misuse of the public Google OAuth API. Your first link clearly states: "A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." In other words it is intended for scenarios where you want to allow access to users outside your workspace.

      > Instead, Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes.

      According to your second link the "hd" parameter only tells you what domain the user belongs to, it does not tell you what workspace the user belongs to.

      > You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP

      So Google offers an OAuth integration option that actually restricts access to your specific workspace. Choosing to ignore this option and instead integrating with the option designed for public access from all Google accounts, and then calling it a vulnerability when someone can login with an account from another workspace, is frankly, absurd.

      Reply View 2 replies
      • johnmaguire a day ago

        > This is a misuse of the public Google OAuth API. Your first link clearly states: "A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." In other words it is intended for scenarios where you want to allow access to users outside your workspace.

        > According to your second link the "hd" parameter only tells you what domain the user belongs to, it does not tell you what workspace the user belongs to.

        From the docs:

        > If you need to validate that the ID token represents a Google Workspace or Cloud organization account, you can check the `hd` claim, which indicates the hosted domain of the user. This must be used when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain.

        https://developers.google.com/identity/gsi/web/guides/verify...

        Note also that even Google conflates "domains" with "Google hosted domains" with "Google Workspace or Cloud organization accounts."

        > Choosing to ignore this option and instead integrating with the option designed for public access from all Google accounts, and then calling it a vulnerability when someone can login with an account from another workspace, is frankly, absurd.

        At this point, if you still believe calling this a vulnerability is absurd, I don't think there's anything more I can say to convince you. Google paid out the bounty because they didn't believe it was abusrd.

        I personally think that the best counterargument to calling it a vulnerability is: "well, sure, Google is reusing the Google Workspace identifier for different workspaces, which could be used to impersonate a user; but if you own the domain, you can also receive email as that user and reset the account that way."

        Reply View 1 reply
        • nodamage a day ago

          I suppose this comes down to the interpretation of the documentation. Note that it only says "a workspace", not "a specific workspace" or "which workspace".

          1) The "hd" claim tells you that the user is a member of a workspace. If the user is a member of a workspace it tells you the domain name of that workspace.

          2) The "hd" claim tells you which specific workspace the user is a member of.

          You are taking interpretation (2) whereas I am taking interpretation (1). I believe interpretation (1) is correct given the next sentence says you can use the "hd" claim to restrict access to only members of certain domains. If interpretation (2) was intended, they could have instead said you can use the "hd" claim to restrict access to only members of a certain workspace.

          If Google is at fault for anything here it is for writing confusing documentation, however given the totality of the documentation where:

          a) Google describes public applications as intended for logins from all Google accounts regardless of workspace, and

          b) Google offers the internal application option for situations where you want to restrict logins to users of a specific workplace,

          I'm going to stand by my conclusion that the real fault lies with service providers choosing the wrong integration option in the first place and then making invalid assumptions about what information the "hd" claim supplies in the public option.

          Reply View 0 replies
    • Terretta 3 days ago

      > Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes.

      Saving a click: "hd" means "hosted domain"

      hd — The domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization. You must check this claim when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain

      I can see value to that being a human readable string, and can see the value of "example.com" being able to be used to SSO for employees of both Example Inc. 1.0, and Example LLC 2.0.

      That said, does seem an "hduuid" could be available for those who care, but mysteriously don't care enough to cancel their other SaaS relationships that use OIDC or SAML SSO.

      Reply View 0 replies
anon84873628 4 days ago

It seems there are two possible problems.

The first is whether taking over a lapsed domain allows you to takeover an existing Google Workspace (or Cloud Identity) organization. This it what houses the corporate email accounts and OAuth client registrations. If Google allows this scenario then the linked account takeover is simply one symptom / side effect among many. TFA is not clear on whether this step actually happened... I assume not, since if it were the case we'd be talking about direct access to the Google account data rather than only linked SP accounts.

The second is when an SP doesn't properly use the `sub` claim as a unique identifier. It sounds like some products don't understand this requirement and why it "seems to change 0.04%" of the time. I do agree that a unique identifier for the org itself would be a good addition to the token.

That said, I'm still not clear how the second problem manifests if the old OAuth client creds (housed in the old Workspace org id) are invalid. Presumably attacker can login to the SP admin account using just email based password recovery, then reconfigure the OAuth integration with new secrets. In that case the SP is failing to do MFA on the email login.

Would love to hear if I'm missing something.

Reply View 2 replies
  • tsimionescu 4 days ago

    > That said, I'm still not clear how the second problem manifests if the old OAuth client creds (housed in the old Workspace org id) are invalid.

    As far as I understand, this is not a necessary step. The SP is configured to trust Google's public OAuth IdP, not a specific Google Workspace account. So there are no special secrets shared between the old Google Workspace account and, say, Slack. The Slack org trusts any user that Google's public OAuth IdP says is a valid user in the example.com domain. Slack doesn't have to do any MFA for these accounts, they trust Google did that already.

    Now, you may not be able to access the Slack org admin account in this way, say to add/remove users or delete the org. But you can access all of the other information that any random employee in the org could access back when it was setup, including a list of all other users in the org.

    Reply View 1 reply
    • anon84873628 4 days ago

      Ah, right, Slack can have their own public oath client which is used for the code grant.

      So what happens is: 1. New Workspace org created with same (old) domain name 2. Same domain name is sent in `hd` property, existing email address sent in the `email` property, new uuid in the `sub` property.

      If the app is only matching on email instead of sub, then it will grant access to previous user data. Additionally, even if it makes a new user based on the new sub, it may still grant access to other SP resources associated with the existing domain based on the email address or hd value.

      Instead there needs to be something like `hd` but uniquely identifying the Workspace org entity itself, not just the domain.

      Reply View 0 replies
patmcc 4 days ago

>>>The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y".

Google is telling other sites that it's bob@DankStartup.com - isn't that true? Isn't this on DankStartup to close down operations cleanly?

Reply View 22 replies
  • tsimionescu 4 days ago

    It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.

    There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.

    Reply View 7 replies
    • freedomben 4 days ago

      Whoever has access to the inbox and account for bob@DankStartup.com is bob@DankStartup.com. If Google was being asked if the SSN for bob is 123-45-6789 and they were saying yes, then I would agree that's an issue, but all Google is saying is "this person can authenticate to our services as bob@DankStartup.com" and that is true.

      Reply View 3 replies
      • tsimionescu 4 days ago

        But the new owner does not have access to the inbox or any other account info of the old bob@DankStartup.com. They're completely separate accounts, with the same email address. Plus, Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns (though per the article, it seems that may not work properly).

        And legal relations just don't work this way. A person is who they are, and it is that person who has legal access to whatever data was stored in their Slack. Another person who happens to have the same email some time later doesn't have any right whatsoever to that same data. OAuth exists to help secure this type of legal relation, not to establish a completely fictitious identity.

        Reply View 2 replies
    • patmcc 4 days ago

      >>>It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.

      Does Google have any reliable way of knowing that?

      >>>There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.

      I have a personal google workspace account with a few domains. At some point I might want to spin one off to be its own (maybe I start a company). But I'd still expect pat@mydomain.com to keep working throughout. So that's 1 situation.

      Reply View 2 replies
      • tsimionescu 4 days ago

        > Does Google have any reliable way of knowing that?

        Yes, Google knows this is a new Google Workspace account using the same domain as the old one.

        > I have a personal google workspace account with a few domains. At some point I might want to spin one off to be its own (maybe I start a company). But I'd still expect pat@mydomain.com to keep working throughout. So that's 1 situation.

        That should be a separate feature of Google Workspace, where you can transfer an identity, it shouldn't be automatic. And it shouldn't even be tied to the domain name. If you decided that you prefer the domain to be pat@mybetterdomain.com, you'd still want to have access to the old Slack conversations or whatever. Conversely, if you lost access to the mydomain.com domain (say you forgot to renew it, or some legal entity sued for it because it was their trademark or whatever), I'm certain you wouldn't want the new owners to then have access to your Slack or any other data, just because they have the same domain name.

        Reply View 1 reply
        • patmcc 3 days ago

          >>>Yes, Google knows this is a new Google Workspace account using the same domain as the old one.

          I agree it knows that, but it doesn't know:

          >>>It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.

          How should it verify that? Should it? If you buy a domain that was used ten years ago, do you want google to say "well, we can't let you use contact@newDomain.com, someone used it previously and it may be confusing".

          >>>I'm certain you wouldn't want the new owners to then have access to your Slack or any other data, just because they have the same domain name.

          Maybe nobody should be using domain name and/or email address as authentication, but that ship has sailed in 100 different ways.

          Reply View 0 replies
  • grepfru_it 4 days ago

    Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this

    Reply View 5 replies
    • mansilladev 4 days ago

      Yes, this. I also use a service to capture all emails (catch all) so that I can detect any loose ends that might have been overlooked. Services like ForwardMX or Cloudflare can do this for you at relatively low (or no) cost.

      Reply View 0 replies
    • jedberg 4 days ago

      Is the hope that this sort of attack is just less useful in 10 years? What happens after 10 years?

      Reply View 3 replies
      • stackghost 4 days ago

        Presumably after 10 years of failing to collect on their invoices, Microsoft would have killed your O365 account, so there's one fewer SaaS account left to log into.

        Reply View 0 replies
      • grepfru_it a day ago

        Common sense would dictat that you have sunset your business by this time.

        Reply View 0 replies
  • cortesoft 4 days ago

    Sure, but DankStartup failed and doesn’t exist anymore. If I am just a lowly employee, I can’t force the failed startup owners to properly shutdown, and now my payroll information is available to hackers.

    What is my remedy?

    Reply View 5 replies
    • patmcc 4 days ago

      Probably sue the failed startup owners for negligence?

      If DankStartup left all your HR files lying around in their office and the guy who bought it five years later found them, well, DankStartup should have shredded them. It'd sure be nice if the cleaners shredded them for you, but I wouldn't count on it (nor make them liable).

      Reply View 1 reply
      • dragonwriter 3 days ago

        > Probably sue the failed startup owners for negligence

        The owners generally aren't liable (assuming or corp or LLC), and if the company would have been liable, that liability probably died with the firm.

        Reply View 0 replies
    • DrillShopper 4 days ago

      In a rational world the remedy would be to sue Google for exposing your payroll information.

      Reply View 2 replies
      • dragonwriter 3 days ago

        Google is neither the party holding the payroll information nor the party that chose to make it available on terms that are insecure against loss of control of the domain, why would it be rational for them to be liable?

        Reply View 1 reply
  • Salgat 4 days ago

    Login credentials are more than just the email used, and should not be conflated with identity. To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others, especially since internally google knows and treats it as a separate account that just happens to have the same e-mail. The e-mail should only be used as metadata for contact info.

    Reply View 1 reply
    • jsnell 4 days ago

      > To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others

      But they are providing a unique, stable, never reused identifier tied to the account, as has been mentioned a number of times in this thread. It's the "sub" field[0], whose entire purpose is to be the unique identifier for tying the IDP's data to the RP's data.

      What they're not doing is to provide that unique id in the "email" field, because the purpose of the email field is to contain the email address. The documentation even specifically tells not to use it as the primary identifier.

      > The e-mail should only be used as metadata for contact info

      Indeed. But that's up to the relying party. The only way to prevent them from checking the wrong field would be to not provide them the email address at all, even when they're explicitly requesting it.

      [0] https://developers.google.com/identity/openid-connect/openid...

      Reply View 0 replies
arnarbi 4 days ago

> They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people

That is not quite true, the sub field will be different.

Reply View 5 replies
  • Ninn 4 days ago

    But authors does imply that sub will also change in place for users in step #1, without the workspace beeing recreated. And as such the sub is not usable as a general identifier for the user resource differentiation.

    Reply View 2 replies
    • anon84873628 4 days ago

      The sub property appearing to change for the same email address is a valid scenario. SPs failing to respect that scenario because they don't understand it, or because it's not what some of their users want, is not a valid excuse.

      https://support.google.com/a/answer/33314?hl=en&co=DASHER._F...

      To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it. I believe other IdPs like Okta and Entra have equivalent features too.

      Reply View 1 reply
      • Ninn 4 days ago

        > To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it

        I think everyone, including the authors hopefully agrees with that logic and sentiment. And that would be the literal point of the sub claim after all!

        But the implication in the article is still, as i read it, that it changes in place in practice, and not in the case of re-creating the user under the same workspace. But i obviously do not have the background to clarify!

        Reply View 0 replies
  • tsimionescu 4 days ago

    This is not necessarily useful. The sub field only indicates that this is a different user, which maybe protects the private info of the old user. However, a big part of OIDC integration is to automatically allow any valid user registered with the IdP to automatically have access to the corporate account, and to any company-wide resources, which can still include very sensitive information.

    Reply View 0 replies
  • Dylan16807 4 days ago

    If by "same people" you mean recognizing a specific user, yes the sub field changes.

    If by "same people" you mean being able to tell whether a new user is part of the same organization, the sub field is useless and no other field has this information either.

    Reply View 0 replies
PKop 4 days ago

Yes but he's saying the data on 3rd-party websites should be deleted by the failed startup when they shutdown not just left to sit there.

Reply View 7 replies
  • PeterFBell 4 days ago

    He's right, but having failed a number of times, after you've put all your savings into the business, fired all your team, notified and disappointed all of your investors and customers, helped your team find new gigs, filed all the dissolution paperwork, handled all the taxes, disposed responsibly of all of the assets and you now find yourself out of work and often out of cash, occasionally you'll forget to jump through all the hoops to close down all of the SaaS accounts before you stop paying the bill personally to host the email accounts.

    Of course perfect world you shut down earlier and in a more orderly fashion, but there are so many cases of companies almost failing and then not, it's hard to shutter a company when there is a chance you may go out of business - especially when you feel you're getting close to another raise or becoming default alive :(

    Reply View 1 reply
    • [removed] 3 days ago
      [deleted]
      Reply View 0 replies
  • mikeryan 4 days ago

    There’s an interesting question on service providers responsiblity who use Oauth for primary auth.

    Should they reset all access to a company account if a domain transfers or becomes publicly available?

    Reply View 0 replies
  • scarface_74 4 days ago

    There are some 3rd party accounts that can be accessed via your SSO or via your personal credentials once you leave. The main ones I can think of is your brokerage account containing your 401K and vested RSUs and your payroll provider like ADP and Paylocity. You still need to have access to past paystubs and end of year tax documents.

    Reply View 3 replies
    • anon84873628 4 days ago

      SSO should stop working when the IdP org is disabled/deleted. IdPs should not allow the org to be resurrected based solely on domain ownership alone. And if a new org is created with the same domain, the SP will need to be reconfigured with new OAuth client creds, and should be relying only on the `sub` claim anyway.

      Any accounts you need after leaving a company should be tied to your personal email.

      Reply View 2 replies
      • scarface_74 4 days ago

        My brokerage account could be accessed by both. I agree that is how it should work. But my brokerage account provider is never told to disable access via my IdP. It’s up to my former IdP to not do something stupid like giving someone else my old email address.

        Reply View 1 reply
        • necovek 4 days ago

          It's not IdP's responsibility to "fix" the internet.

          Just like someone can buy a home and will get mail targeting a previous owner, the same happens with domain names and emails.

          Domains are, however, much cheaper and more abundant, so it happens more often.

          Reply View 0 replies
otabdeveloper4 4 days ago

I don't see the problem here.

We've already settled on DNS being the auhoritative authentication key for everything. If you bought the domain then you've bought the corporate identity. It's working as designed.

Reply View 2 replies
  • dinoqqq 4 days ago

    The flaw is the fact that companies go bankrupt and their data should die with them. In case of bankruptcy it might be impossible to hold on to your DNS and therefore risking old company data leaking.

    Reply View 1 reply
    • echoangle 3 days ago

      Can’t you just actively delete the company accounts when closing down?

      Reply View 0 replies
rahkiin 4 days ago

Any domain takeover allows email takeover which allows you to send password reset emails for former employees. Does not matter if it is with oauth or not

Reply View 8 replies
  • mtkd 4 days ago

    And many vendors will send "restart your service today for $x" for months afterwards so data not deleted

    Some SaaS ecommerce platforms and email marketing services will likely give a restarted domain entire customer databases ...

    Reply View 2 replies
    • rahkiin 4 days ago

      There should be some service for permanently destroying a domain with a single prepaid cost. Somehow preventing bankruptcy laws from getting the domain.

      Pay X$ up front, then Y$ per month to keep active. Once you cannot pay, it gets blocked forever (paid for by the up front cost). Owned by your service provider so not part of your firesale

      Reply View 1 reply
      • ocdtrekkie 4 days ago

        What happens when your service provider that owns your domain collapses?

        Reply View 0 replies
  • anon84873628 4 days ago

    Those password resets should have some sort of MFA step.

    Reply View 4 replies
    • jpc0 4 days ago

      Sue lost hee phone, she used KeePass for everything and didn't back it up. She get some support from IT, what do they do to solve Sue's problem?

      They reset her password and 2FA and have her redo them. She probably gets a lecture about backups or she spurns a brand new company policy that "Everyone should now use LastPass and nothing else is supported".

      If they as administrators cannot do that, Sue has now lost significant business data, there will be a dexent amount of work stopped to get Sue onboarded again and this is a significant issue.

      An auditable log that X reset Sue's password ane 2FA codes at x time while at x location with biometric authentication is pretty secure. If X also ca nnot touch those logs the next strawman falls apart.

      Reply View 3 replies
      • anon84873628 4 days ago

        What does this have to do with the scenario above? Of course you can reset the corporate SSO account as many times as you want. The point is that federated apps with a password reset flow should have some sort of MFA.

        Reply View 2 replies