`cb login` with MFA doesn't interact quite right with SSO

[fdr]

I enabled SSO for my team, and per Crunchy's documentation, logging in with that method on the web site does not prompt me for Crunchy 2FA codes, relying on my SSO provider. Sensible, as that provider has MFA policy I can set for everything that uses it. Nice for auditing. Everything works expected on the Bridge web site.

but, cb login prompts me for a crunchy MFA, not my SSO MFA. My account seems to be in both the SSO world and the first-party-account/MFA world, and the abstraction is leaking a bit. It's weird but I'm not sure what I should do about it.

[abrightwell]

Yeah, I was able to reproduce on my end. I'll discuss it with the team.

[brandur]

@fdr I think this may have been discussed in a support ticket at some point, but basically what's happening here is:

• When logging in via SSO, we assume that a user's who's enabled MFA on Crunchy probably also has it on with their SSO provider, so we don't require an MFA code under this condition because assuming the user was starting from a fresh slate, they'd have to enter two MFA codes in quick succession (one for their SSO provider, one for us), which would be very annoying.
• Bridge has a concept of a "sensitive action" like changing an email or provisioning a new API key that requires an MFA prompt every so often. Authorizing a new CB is one of these, so what's happening is that you're logging in via your SSO provider to auth a CB, but then get hit by a required MFA prompt immediately because a sensitive action is being performed.

I suppose that a potential UX improvement on our end might be to not require MFA on sensitive action as long as a user has logged in via SSO very recently. I'll see if that might be a change we could make without too much trouble.

In your case, what you might want to consider is going to your account settings and removing your password:

Then disabling your Crunchy MFA.

This would keep things relatively safe because it'd no longer be possible to use your account without SSO, and since MFA is presumably enabled there, all sensitive identity-related operations will generally require an MFA through the provider.

There'd be a little loss in security around a long-lived browser session, but depending on how hardened your endpoint security is, that might be tolerable.