Personal access tokens

[muellerj]

I am looking to build something that allows access to rodauth-protected resouces in cases where the typical username/password or 2FA mechanisms are not available (e.g. CLI or API access). GitHub and others implement something along these lines using "Personal Access Tokens", which are tied to an account and can have "scopes" attached to them. In contrast to typical OAuth tokens however, these are not requested automatically by an authorized app but instead built by the user manually. As such, they are not really suited for rodauth-oauth, see the corresponding issue.

Does anyone have experience implementing such a feature with rodauth? Is the existing JWT feature useful here?

Thanks in advance,
Jonas

[jeremyevans]

I don't have much to add here, other than saying that "scopes" sound more like authorization and less like authentication, and Rodauth is solely an authentication framework, not an authorization framework. That being said, it's definitely possible to implement something like this as a Rodauth feature, but I'm not aware of an existing implementation.

[muellerj]

As far as I understand, it is a mixture of both. The simplest possible implementation has no scopes and can subsequently do everything that the user can. If someone wanted to bolt additional authorization on, that would serve as a good starting point.

I will take a stab at an implementation as a Rodauth feature. Is there a mechanism for feature-specific columns or should I simply add them to the README and the migrations in ./spec?

[jeremyevans]

By "definitely possible to implement something like this as a Rodauth feature", I was just stating it is technically possible to do this. I apologize if I gave the impression that this is something I would accept as part of Rodauth. Note that Rodauth does not differentiate between internal and external features, both are loaded the same way. If this is something you are interested in, I encourage you to work on it as an external feature. You just need to make sure that your feature is loadable by require "rodauth/features/$feature_name". You can see how the existing features are designed, and base your external feature on that. The internals guide may be helpful: https://rodauth.jeremyevans.net/rdoc/files/doc/guides/internals_rdoc.html. Note that Rodauth's general approach is a separate database table per feature (assuming the feature needs to store data).

[muellerj]

No offense taken. I will try an implementation as an external feature.

[muellerj]

No offense taken. I will try an implementation as an alternative feature. On 24. Mar 2023, at 15:53, Jeremy Evans ***@***.***> wrote: By "definitely possible to implement something like this as a Rodauth feature", I was just stating it is technically possible to do this. I apologize if I gave the impression that this is something I would accept as part of Rodauth. Note that Rodauth does not differentiate between internal and external features, both are loaded the same way. If this is something you are interested in, I encourage you to work on it as an external feature. You just need to make sure that your feature is loadable by require "rodauth/features/$feature_name". You can see how the existing features are designed, and base your external feature on that. The internals guide may be helpful: https://rodauth.jeremyevans.net/rdoc/files/doc/guides/internals_rdoc.html. Note that Rodauth's general approach is a separate database table per feature (assuming the feature needs to store data). —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>