Users & Authentication
Nearly every app we build these days requires some sort of authentication, and probably a user account to go along with it. Even if your app is an oddball and doesn't need this, user accounts provide us with a well-understood set of use cases that will serve as an excellent case study.
Let's put some of our newfound Phoenix knowledge into practice as we implement a secure user account feature set. The goal will be to reduce explicit management of authorization & authentication on a per-resource basis as much as possible.
-
Users & AuthenticationEXERCISE: Registration
Creating new users will serve to highlight a few concepts at the model layer
- Server-side validation, including writing our own validator
- Safely handling passwords
- Keeping slightly different changeset-generating functions organized
We'll also have an opportunity to start defining routes that require a user to be authenticated, and routes that don't.
-
Users & AuthenticationEXERCISE: Login & Logout
For our purposes, we'll use a JSON Web Token (JWT) and the OAuth 2 password grant standard, as a mechanism and vehicle for authentication. You will be provided with a client-side app that will talk to our Phoenix, via JSON.
We'll validate a user's credentials in a way that's not incredibly sensitive to timing or brute force attacks, and then assemble our little piece of session state (the JWT) before encrypting it and handing it back to the client.
-
Users & AuthenticationEXERCISE: Roles
We often have a concept of roles (or an equivalent concept masquerading as other flags/fields) built on top of our authentication. We'll add roles to our JWT, and design a plug that will raise an error if a user attempts to access a controller action without having the required roles.
-
Users & AuthenticationWrap Up & Goodbye
We'll recap everything we've learned