opcotech/elemo

# Authentication and Authorization

| author                 | created at     | updated at     | status   |
|:-----------------------|:---------------|----------------|:---------|
| _your GitHub username_ | _current date_ | _current date_ | proposed |

## Abstract

Authentication and authorization plays an important role in Elemo's ecosystem.
Users may have permissions assigned globally, on organization level, or even on
project level.

With the exception of system roles, every role and permission should have been
managed by the authorized users. Keeping that in mind, the authorization and
authentication system should be flexible enough to support these needs, but be
secure at the same time.

Also, the system must support (at least) OAuth2 flows to prepare for third-party
applications as well as API access.

## Decision

Elemo's authentication system is going to be based on OAuth2, implemented using
[go-oath2]. OAuth2 allows us to define scopes to access resources and works well
with OpenAPI generators we use to generate HTTP handlers from specification.

For authorization we could use complex solutions, like [Open Policy Agent],
though that would be overkill for now. In a later point of time, it may would
worth to add OPA, but it would just add extra complexity at the moment.

The authorization will be solved by checking the following, depending on need:

* The (context) user's relation(s) with a given resource - this is necessary For
  cases when we want to allow/disallow resource access based on a relation. Ex.
  allow access to a ticket if the user has any relations with the project where
  the ticket belongs to.
* The (context) user has a direct permission on a resource
* The (context) user has a system role that allows access to a resource

Implementation-wise, the system roles will take precendence, though the rest
depends on the developer.

The authentication backend will be using the relational database to store client
and token data. The rest (authorization) is done on graph database level. The
authenticated user sessions shall be stored in Redis to have a shared session
store across running replicas.

[go-oauth2]: https://github.com/go-oauth2/oauth2
[Open Policy Agent]: https://www.openpolicyagent.org/

## Consequences

We have a flexible, yet powerful authentication and authorization system, that
can log in and out our users, storing their session in Redis for fast and shared
access.

The go-oauth2 library is mature, but not the most robust. It may happen in the
future that we want to replace it with someting else, like [fosite], which is
a lot more complex and harder to implement, but allows OpenID connect.

[fosite]: https://github.com/ory/fosite

## References

None.