Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add has verified factor mfa claim #1838

Closed
wants to merge 2 commits into from
Closed

Conversation

J0
Copy link
Contributor

@J0 J0 commented Nov 13, 2024

What kind of change does this PR introduce?

Supercedes #1823 and adds a HasVerifiedFactor claim so that it's easier to enforce aal2 only if MFA is enabled on a user's account. Naming is open for discussion

Additional context

Internally, prior to deploy, we will need to update tests (if any) to reflect that we have added a new claim. As this is an additive change, it should not break any existing setups

@J0 J0 requested a review from a team as a code owner November 13, 2024 05:25
@@ -108,6 +108,7 @@ type AccessTokenClaims struct {
AuthenticatorAssuranceLevel string `json:"aal,omitempty"`
AuthenticationMethodReference []models.AMREntry `json:"amr,omitempty"`
SessionId string `json:"session_id,omitempty"`
HasVerifiedFactor bool `json:"has_verified_factor"`
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be set to false if there are no factors / nil slice so there's no need for an omitempty specifier

@coveralls
Copy link

Pull Request Test Coverage Report for Build 11811241578

Details

  • 9 of 9 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.02%) to 57.056%

Totals Coverage Status
Change from base Build 11795500330: 0.02%
Covered Lines: 9550
Relevant Lines: 16738

💛 - Coveralls

@J0 J0 changed the title fix: add has verified factor mfa claim feat: add has verified factor mfa claim Nov 13, 2024
Copy link
Member

@kangmingtay kangmingtay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@J0 can we also add a test to check that the value in the claim is expected?

@@ -108,6 +108,7 @@ type AccessTokenClaims struct {
AuthenticatorAssuranceLevel string `json:"aal,omitempty"`
AuthenticationMethodReference []models.AMREntry `json:"amr,omitempty"`
SessionId string `json:"session_id,omitempty"`
HasVerifiedFactor bool `json:"has_verified_factor"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we call this mfa_enabled ? seems easier to understand vs has_verified_factor?

Copy link
Contributor

@cstockton cstockton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should fix this in documentation if necessary. Essentially this change should be:

mfa_enabled := ("mfa" in token.amr)

If we are not currently populating AMR with RFC 8176 values, I think that would be a great change to make in place of this one.

@J0
Copy link
Contributor Author

J0 commented Nov 14, 2024

Currently we don't use amr values as per RFC 8176 values. Could look into switching but think that might be part of a bigger discussion

The above convention would work though though we'd need to make an exception for totp as it's not prefixed with mfa/

MFA methods:

totp
mfa/webauthn
mfa/phone

@J0
Copy link
Contributor Author

J0 commented Nov 19, 2024

Closing in favour of documentation, should evaluate RFC8176 at some point

@J0 J0 closed this Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants