Packages
ash_authentication
5.0.0-rc.14
5.0.0-rc.15
5.0.0-rc.14
5.0.0-rc.13
5.0.0-rc.12
5.0.0-rc.11
5.0.0-rc.10
5.0.0-rc.9
5.0.0-rc.8
5.0.0-rc.7
5.0.0-rc.6
5.0.0-rc.5
5.0.0-rc.4
5.0.0-rc.3
5.0.0-rc.2
5.0.0-rc.1
5.0.0-rc.0
4.15.0
4.14.2
4.14.1
4.14.0
4.13.7
4.13.6
4.13.5
4.13.4
4.13.3
4.13.2
retired
4.13.1
retired
4.13.0
4.12.0
4.11.0
4.10.0
4.9.9
4.9.8
4.9.7
4.9.6
4.9.5
4.9.4
4.9.3
4.9.2
4.9.1
4.9.0
4.8.7
4.8.6
4.8.5
4.8.3
4.8.2
4.8.1
4.8.0
4.7.6
4.7.5
4.7.4
4.7.3
4.7.2
4.7.1
4.7.0
4.6.4
4.6.3
4.6.2
4.6.1
4.6.0
4.5.6
4.5.5
4.5.4
4.5.3
4.5.2
4.5.1
4.5.0
4.4.9
4.4.8
4.4.7
4.4.6
4.4.5
4.4.4
4.4.3
4.4.2
4.4.1
4.4.0
4.3.12
4.3.11
4.3.10
4.3.9
4.3.8
4.3.7
4.3.6
4.3.5
4.3.4
4.3.3
4.3.2
4.3.1
4.3.0
4.2.7
4.2.6
4.2.5
4.2.4
4.2.3
4.2.2
4.2.1
4.2.0
4.1.0
4.0.4
4.0.3
4.0.2
4.0.1
4.0.0
4.0.0-rc.6
4.0.0-rc.5
4.0.0-rc.3
4.0.0-rc.2
4.0.0-rc.1
4.0.0-rc.0
3.12.4
3.12.3
3.12.2
3.12.1
3.12.0
3.11.16
3.11.15
3.11.14
3.11.13
3.11.12
3.11.11
3.11.10
3.11.9
3.11.8
3.11.7
3.11.6
3.11.5
3.11.4
3.11.3
3.11.2
3.11.1
3.11.0
3.10.8
3.10.7
3.10.6
3.10.5
3.10.4
3.10.3
3.10.2
3.10.1
3.10.0
3.9.6
3.9.5
3.9.4
3.9.3
3.9.2
3.9.1
3.9.0
3.8.0
3.7.9
3.7.8
3.7.6
3.7.5
3.7.4
3.7.3
3.7.2
3.7.1
3.7.0
3.6.1
3.6.0
3.5.3
3.5.2
3.5.1
3.5.0
3.3.1
3.3.0
3.2.2
3.2.1
3.2.0
3.1.0
3.0.3
Authentication extension for the Ash Framework.
Current section
Files
Jump to
Current section
Files
documentation/tutorials/password.md
<!--
SPDX-FileCopyrightText: 2022 Alembic Pty Ltd
SPDX-License-Identifier: MIT
-->
# Password Authentication
## With a mix task
You can use `mix ash_authentication.add_strategy password` to install this strategy.
The rest of the guide is in the case that you wish to proceed manually.
## Add Bcrypt To your dependencies
This step is not strictly necessary, but in the next major version of `AshAuthentication`,
`Bcrypt` will be an optional dependency. This will make that upgrade slightly easier.
```elixir
{:bcrypt_elixir, "~> 3.0"}
```
## Add Attributes
Add an `email` (or `username`) and `hashed_password` attribute to your user resource.
```elixir
# lib/my_app/accounts/user.ex
attributes do
...
attribute :email, :ci_string, allow_nil?: false, public?: true
attribute :hashed_password, :string, allow_nil?: false, sensitive?: true
end
```
Ensure that the `email` (or username) is unique.
```elixir
# lib/my_app/accounts/user.ex
identities do
identity :unique_email, [:email]
# or
identity :unique_username, [:username]
end
```
## Add the password strategy
Configure it to use the `:email` or `:username` as the identity field.
```elixir
# lib/my_app/accounts/user.ex
authentication do
...
strategies do
password :password do
identity_field :email
# or
identity_field :username
end
end
end
```
Now we have enough in place to register and sign-in users using the
`AshAuthentication.Strategy` protocol.
## Reset request timing and account enumeration
When you configure `resettable` with a sender, the strategy adds a reset request
action. That action returns `:ok` whether or not the identity matches a user, so
the response body does not reveal which accounts exist. The response *time* does.
On a match, the action mints a reset token and then calls your sender inline. On a
miss, it returns straight away. There is no registration option here, so the miss
path always short-circuits. A synchronous SMTP or HTTP-API send adds tens to
hundreds of milliseconds, which is enough to tell the two paths apart.
An asynchronous sender closes that gap. A sender that enqueues a job and returns
`:ok` immediately keeps delivery latency off both paths. The difference then falls
to one JWT signing operation, about 27 microseconds. Neither path writes to the
database unless you enable `store_all_tokens?`. At that size the difference is not
measurable across a network. See `AshAuthentication.Sender`, which recommends the
same pattern for retries.