Authentication/permissions/groups
I've thought about this for a while now, and it turns out that implementing an auth system from scratch is very error prone. I'll just give one example, of how you can mess up.
For example, if you have a user who has permissions to edit a fragment, say that fragment is of type 'blogpost', and then they edit the permissions on that fragment to replace the current permissions with 'write' permissions for the 'writers' group, which the user is a part of. Now we have a fragment that can be edited by this user because they're a member of the writers group. Say you then move this user into the 'admins' group. Suddenly the user no longer has permissions to edit the fragment they created. And if they're the last person in the writers group, no one has permissions to edit that fragment anymore. This is solved by always adding the user with 'write' permissions to any object they're modifying the permissions of.
And there are a bunch of tricks like that, that we would have to reinvent. I suggest, instead, following the example of Kinto http://kinto.readthedocs.org/en/latest/api/1.x/permissions.html http://kinto.readthedocs.org/en/latest/api/1.x/groups.html#creating-a-group which has been battle tested to a large degree.
In short, we have groups and users, which are bound to a collection. In our current case, the collection is the blog, so the blog would have groups and users, which can be used for setting very granular permissions on the fragments (and the collection itself).
What we discussed previously, i.e. which group get to see which component, I'd state that it's only configuration and has no effect on permissions or authentication. I.e. a user from group 'writers' could still hack the interface to show the 'admin'-level component, but there would be nothing of value (for the hacker) there, as the system would not allow reading on a backend level. So stating which component which group or user can view is merely a soft mask over the front end implementation, and is not meant to be, nor does it need to be, hack-safe.
That's my current thinking, happy to get comments or other reference implementations. Kinto seems to match our system very well, so the transferal of that functionality should be straightforward.