Like any other API, there some methods that should check the user authorizations to grant or forbid some features and data access. To standarize this behaviour all services must implement their checks in the way this wiki specifies.
The user api_token
Every user has linked to its account a api_token which is created in the moment the user itself is registered on the system. This token is just a json web token with the id embedded.
For the sake of simplicity the system only uses a single token with a really long expiration date. This decision is made to avoid the auth roundtrips during long running operations, enforcing the client code to reauthenticating and generating a new token every N minutes making the code far more complex (handling auth expired errors and such). In the future this system should be able to handle multiple credentials and temporal tokens.
Service authorization
Each service should identify the user using his api_token, which returned by the login method or readable via its profile. This value should be sent using the header Authentication using the following format:
Authentication: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Once the token is available on the securized service, it should rely on the user service to perform the authentication checking.