Allow disabling local password through broker.conf by shiv-tyagi · Pull Request #1234 · canonical/authd

shiv-tyagi · 2026-02-01T17:32:59Z

Closes #726

This adds the disable_local_password option to the broker.conf. When set to true, the local password authentication mode is disabled completely and the user is forced to authenticate with device authentication.

In device authentication mode, the set local password step after successful authentication is skipped as well because it is not needed anymore.

I have tested this locally and it works as described.

Signed-off-by: Shiv Tyagi <shivtyagi3015@gmail.com>

…rd` in broker.conf Signed-off-by: Shiv Tyagi <shivtyagi3015@gmail.com>

codecov · 2026-02-01T17:55:55Z

Codecov Report

❌ Patch coverage is 81.81818% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.54%. Comparing base (8304517) to head (ba71c03).
⚠️ Report is 332 commits behind head on main.

Files with missing lines	Patch %	Lines
authd-oidc-brokers/internal/broker/broker.go	71.42%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1234      +/-   ##
==========================================
- Coverage   87.64%   80.54%   -7.10%     
==========================================
  Files          91       20      -71     
  Lines        6231      987    -5244     
  Branches      111        0     -111     
==========================================
- Hits         5461      795    -4666     
+ Misses        714      192     -522     
+ Partials       56        0      -56

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

adombeck

Thank you for working on this, @shiv-tyagi! There's still a bit of work for us to do here, most notably we will have to figure out how to unlock the keyring when there's no local password.

adombeck · 2026-02-02T12:54:29Z

-	session.nextAuthModes = []string{authmodes.NewPassword}

-	return AuthNext, nil
+	// Only require password creation if local password authentication is not disabled


Suggested change

// Only require password creation if local password authentication is not disabled

// Require password creation unless local password authentication is disabled

adombeck · 2026-02-02T14:10:27Z

+##
+## When enabled:
+## - Users will not be able to create or use local passwords
+## - Device authentication will be required for every login


Suggested change

## - Device authentication will be required for every login

## - Device authentication will be required for every authentication attempt,

## including logins and privileged operations (e.g. sudo, polkit actions)

adombeck · 2026-02-02T14:11:50Z

+## - Device authentication will be required for every login
+## - Local password authentication mode will not be offered
+##
+## Important: Enabling this option prevents offline login entirely.


Suggested change

## Important: Enabling this option prevents offline login entirely.

## Important: Enabling this option prevents offline authentication entirely.

adombeck · 2026-02-02T14:19:07Z

+	if !b.cfg.disableLocalPassword {
+		session.nextAuthModes = []string{authmodes.NewPassword}
+		return AuthNext, nil
+	}


Another consequence of not creating a local password is that the keyring can't be unlocked. #1190 also won't fix it in that case.

Okay. We can discuss about this. I will post here if I get an idea about this.

I made a proposal here: #1190 (comment)

adombeck · 2026-02-02T14:20:52Z

+## When enabled:
+## - Users will not be able to create or use local passwords
+## - Device authentication will be required for every login
+## - Local password authentication mode will not be offered


Note to self: We should probably point users to force_provider_authentication here, and maybe briefly discuss the use cases of force_provider_authentication and disable_local_password.

Yes, force_provider_authentication only comes into play when the user tries logging in through local password.

Maybe we can add an explanation mentioning about when force_provider_authentication makes sense.

adombeck · 2026-02-02T14:25:01Z

+	if !b.cfg.disableLocalPassword {
+		session.nextAuthModes = []string{authmodes.NewPassword}
+		return AuthNext, nil
+	}


Note to self: Manually test:

ssh

sudo

pkexec

unlocking keyring

Ideally we should add e2e tests for those.

Also test what happens when you lock the screen when there's no local password. Can the screen even be locked? Does it offer device authentication to unlock the screen? Document the behavior (and point out the terrible UX of having to use device authentication to unlock the screen).

denisonbarbosa · 2026-07-23T11:26:55Z

Hey, @shiv-tyagi! Are you still around? Can you address @adombeck's comments on the PR and rebase it on main so we can move forward with this?

shiv-tyagi · 2026-07-23T11:28:21Z

Hey @denisonbarbosa, yes I am working on it. Will do it tonight. Thanks.

3v1n0 · 2026-07-23T12:52:23Z

I would think we could manage this on per-service options instead (as per #1675) so that we could also disable a particular UI daemon-side, depending on the service.

adombeck · 2026-07-23T13:06:04Z

I would think we could manage this on per-service

I agree that it should be possible to disable the local password per service (e.g. disable it for ssh but enable for sudo). See also #726 (comment)

I'm not sure if it belongs in the authd.yaml though or the broker.conf. It requires some more thought. However, I'm out of office until August 10, so I won't be able to finish the design or review a proposal until then.

shiv-tyagi · 2026-07-23T16:27:07Z

@adombeck will this be in this PRs scope or could be a follow up? If in the scope of this PR, I will hold it off till you return.

adombeck · 2026-07-23T17:11:19Z

Yeah I think it makes sense to first finish the design and then implement it (possibly iteratively). We don't want to merge something that is configured via a setting that we might change soon after, possibly invalidating existing config files. Note that everyone else in the team will also be out of office the next two weeks, so we wouldn't be able to continue here anyway.

shiv-tyagi added 2 commits February 1, 2026 23:08

Allow disabling local password through broker.conf

75a686b

Signed-off-by: Shiv Tyagi <shivtyagi3015@gmail.com>

tests: add cases to test parsing and working of `disable_local_passwo…

ba71c03

…rd` in broker.conf Signed-off-by: Shiv Tyagi <shivtyagi3015@gmail.com>

shiv-tyagi force-pushed the disable-local-password branch from 5495017 to ba71c03 Compare February 1, 2026 17:38

adombeck self-requested a review February 2, 2026 12:51

adombeck reviewed Feb 2, 2026

View reviewed changes

adombeck mentioned this pull request Feb 2, 2026

pam: Set PAM_AUTHTOK on successful authentication #1190

Merged

yetanotheralex mentioned this pull request Apr 29, 2026

authd: option to hide the local broker from the GDM broker picker for OIDC-only deployments #1497

Open

	// Only require password creation if local password authentication is not disabled
	// Require password creation unless local password authentication is disabled

	## - Device authentication will be required for every login
	## - Device authentication will be required for every authentication attempt,
	## including logins and privileged operations (e.g. sudo, polkit actions)

	## Important: Enabling this option prevents offline login entirely.
	## Important: Enabling this option prevents offline authentication entirely.

Uh oh!

Conversation

shiv-tyagi commented Feb 1, 2026

Uh oh!

codecov Bot commented Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

adombeck left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shiv-tyagi Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shiv-tyagi Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

denisonbarbosa commented Jul 23, 2026

Uh oh!

shiv-tyagi commented Jul 23, 2026

Uh oh!

3v1n0 commented Jul 23, 2026

Uh oh!

adombeck commented Jul 23, 2026

Uh oh!

shiv-tyagi commented Jul 23, 2026

Uh oh!

adombeck commented Jul 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov Bot commented Feb 1, 2026 •

edited

Loading

shiv-tyagi Feb 2, 2026 •

edited

Loading

shiv-tyagi Feb 2, 2026 •

edited

Loading