Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions articles/authentication-and-authorization/index.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
---
---
layout: post
title: Authentication and Authorization
prev:
Expand Down Expand Up @@ -44,6 +45,20 @@ your development time up with unreasonable security constraints. If a user tries
in the process destroys their own user account data, that's not a problem. It's only when actions
might affect, compromise, or destroy the data of other users that you need to worry.

That said, think twice about who should own which data.
In lots of websites there's data **about** a user that affects how the
site owners, their servers and their customer service agents will act:

* Email addresses.
* Payment history.
* Premium subscription level and expiration date.
* Confirmed orders' shipping addresses.
* You can probably think of more.

So even though this data is **about** a user, it shouldn't be considered
**theirs** in authorization context.


### Temporary Revocable Access Credentials

Unless you are building an offline-only application designed to store data only in the local browser,
Expand Down