Authorization Dialog
Designs for system-level authorization dialogs. Some of the particulars here are generally relevant to password entry and authentication design patterns.
Goals & Requirements
- Clearly communicate the context of the interaction - in the case of system-level authorization dialogs, it ought to be clear what the user is interacting with
- Ensure that the authorization request doesn't get lost - it is usually required in order for another action to complete, so require that the user responds in a timely fashion
- Don't interrupt the user or surprise them - ideally password prompts should only appear immediately in response to a user action
- In some cases, make it clear that administrator credentials are required
- Hide entered text by default, but allow it to be shown if needed
- Indicate input method and allow it to be changed
- Indicate caps lock state
- Provide feedback on unsuccessful authorization attempts
Non-Goals
- Require the user to allow/deny specific actions
Relevant Art
Windows 10
Mac
GNOME 3.32
GNOME 2
Discussion
Which actions require authorization my depend on the context. For example, installing new software may not be allowed automatically within a supervised or managed account.
Efforts should be made to make the information request difficult to spoof. Perhaps it could even verify information that is passed to it from an application.
It might be interesting to only present the system modal when the requesting app is already focused and otherwise show a notification that says app requires authorization and if I click on that then present a modal.
Tentative Design
Old designs:
Comments