Ways to sign in
On this page
obacht can be set up in four ways, from a server on its own to a login provider that also decides who may do what. Pick the first one that fits; each builds on the one before.
| Who signs in | Who decides what a parent may do | Settings | |
|---|---|---|---|
| 1. obacht on its own | parents and children with a username and password in obacht | obacht: every parent may do everything | none |
| 2. With a login provider | everyone through the provider (Authelia, Keycloak, Authentik, …); no passwords in obacht | obacht: every parent may do everything | oidc.* |
| 3. With a login provider and a policy engine | everyone through the provider | the policy engine, per parent and per child | oidc.*, authzen.* |
| 4. With an account portal | everyone through the provider; the portal creates and removes parents and children's logins | the policy engine, set from the portal | as 3, plus scim.* and back-channel logout |
Devices (phones, PCs, TVs) never sign in as a person: they are paired with a code from the parent app, in every setup. API tokens for your own tools act as the parent who made them.
1. obacht on its own
The first start of the parent app asks for the first parent's username and password. Further parents are added on the Account page, children's logins in the child's Settings (A login for your child). Passwords are checked with argon2; sessions last 30 days. Nothing else to set up.
2. With a login provider
The provider is then the only way in: there are no passwords in obacht, and setting up or adding parents by hand is off. Parents are the members of one group at the provider, checked at every login; they get their obacht account at their first login. A child's login is an account at the provider with the same username as in obacht, outside the parent group. How to set it up: Running obacht at home.
Switching from setup 1: existing parents are taken over by their username at their first login through the provider (their password is deleted); from then on obacht knows them by the provider's id.
3. With a login provider and a policy engine
The provider still decides who is a parent; an OpenID AuthZEN policy decision point such as Keycloak's Authorization Services then decides what each parent may do, for example a grandparent who may only answer extra-time requests. When the engine can't be reached, the answer is no. See Permissions per parent.
4. With an account portal
An account portal in front of the provider (the hosted obacht at obacht.eu has one) runs setup 3 and adds two things a self-hoster with Keycloak or another provider can use too:
- SCIM: the portal creates and removes parents and children's logins in obacht, so a parent removed at the portal loses their sessions and API tokens at once (Accounts from your login provider).
- Back-channel logout: signing out at the provider, or being removed there, ends the sessions in obacht at once (see Running obacht at home).
This page is part of obacht's documentation, licensed under CC BY 4.0. Source on GitHub · CC BY 4.0 · Version: main (2ab2740)