Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication #2

Open
1 of 4 tasks
fabiante opened this issue Aug 27, 2023 · 1 comment
Open
1 of 4 tasks

Authentication #2

fabiante opened this issue Aug 27, 2023 · 1 comment
Labels
epic A large goal generally guiding development

Comments

@fabiante
Copy link
Owner

fabiante commented Aug 27, 2023

At some point, the application will require authentication.

Once users are authenticated, this will allow the service to authorize administration of a purl domain and the contained purls of the given domain.

To me the most flexible route would be to rely on some JWT and to trust some identity provider.

The resolve endpoint should not require authentication. PURLs can't protect their target by having users log in. There may of course be some use to having only logged-in and authorized users get a list of PURLs of a domain (an example). But that is not yet interesting to persurl. If you want this, open an issue.

Patterns / Options

  • Consider supporting popular identity providers: Google, Auth0, Microsoft, Github, Zitadel
  • Consider using Zitadel - I personally want to use this more to evaluate its capabilities
  • Self-managed API keys (simple)
  • Self-managed user accounts Not every wheel needs re-inventing. A good article about that.
@fabiante fabiante added the story User story which adds any value to the project label Aug 27, 2023
@fabiante fabiante added epic A large goal generally guiding development and removed story User story which adds any value to the project labels Sep 20, 2023
@fabiante
Copy link
Owner Author

fabiante commented Sep 22, 2023

I thought about introducing a lightweight user mangement:

  • have a users table
  • have a users_pats table (personal access tokens)

This would allow me to create users manually via the database, create PATs for them and give access to Persurl.

While I'd like to support IdPs such as Google, Microsoft etc., I think that my focus is not on adding support for all those. Instead I want to focus on the core application.

What drives me towards a first, simple solution is another aspect: Even if I started to integrate an OIDC provider, I think I'd still have to create a users table like this:

create table public.users
(
    id        serial,
    google_id varchar(128),
    auth0_id  varchar(128)
);

This table is required because domains and purls have a relationship with a user: The user who creates a domain, owns that domain. Modeling this relationship is simply done by adding a relation between the two tables:

alter table public.domains
    add owner_id int;

alter table public.domains
    add constraint domains_users_id_fk
        foreign key (owner_id) references public.users;

Personal summary: I think having a users table is the first, logical step for managing domain and purl ownership. I'll try to elaborate on that in new github issues as there are multiple topics here. (#81)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic A large goal generally guiding development
Projects
None yet
Development

No branches or pull requests

1 participant