You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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:
createtablepublic.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:
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)
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
Self-managed user accountsNot every wheel needs re-inventing. A good article about that.The text was updated successfully, but these errors were encountered: