I've also just come across Knock, which is not based on Warden like Devise but offers similar authentication to Credible: https://github.com/nsarno/knock
Why am I listing these?
Knock and Devise both allow for scoped authenticatable models, meaning for example that User instances and Admin instances can be authenticated separately. This is one thing which they both do that Credible should also be able to offer. Knock provides a good model for adding such functionality and should be read as inspiration.
Knock is a minimal API authentication setup with no bells and whistles.
Devise has a lot of bells and whistles.
Credible wants to be somewhere between these two, offering an API authentication solution with some bells and whistles like:
Timeoutable Access Token - Knock supports this, with a configurable lifespan
Longlived Refresh Token (currently being added to Credible, not supported by Knock)
Refresh Token Rotation
...and a bunch of authentication strategies like:
Basic Auth and Password Auth (note: basic auth spec has username and password as headers, params-based "password auth" is therefore unique)
Email Auth (see how Medium handles sign-in)
Note also: Common practise now is to have an Auth Server and a Resource Server. Credible is setup in such manner that it can be authentication on both ends.
A typical auth server might provide:
Basic/Password Auth
Email/Confirmation/Invitation Auth
Refresh Token Auth
...whereas any of these will provide an Access Token used for this sole authentication strategy on the resource server:
Access Token/JWT Auth
Right? ... Yeah, I think so.
Credible already supports Password, Confirmation, Invitation... and now also refresh tokens. Oh and access token auth, of course (because it plays both sides). I just have this question: Should it?
Should it, or should Credible be separated into, say, Credible::Auth and Credible::Resource or something like that?
Answer: No. Too much fragmentation for such a small concern. Credible should contain all strategies. There is maybe an argument that resource-server authentication could be extracted into a sub-dependency, maybe "credible-lite" or "credible-access" or something like that. But no more messy fragmentation than that should occur, certainly.
Anyway, inspirations...
I just wanted to list them here so that ideas can be discussed. They should also be linked to as alternatives in the main README.
Credible uses Warden: https://github.com/wardencommunity/warden
It's no secret that Credible takes inspiration from and is looking to be a similar offering to Devise: https://github.com/heartcombo/devise
I've also just come across Knock, which is not based on Warden like Devise but offers similar authentication to Credible: https://github.com/nsarno/knock
Why am I listing these?
Knock and Devise both allow for scoped authenticatable models, meaning for example that User instances and Admin instances can be authenticated separately. This is one thing which they both do that Credible should also be able to offer. Knock provides a good model for adding such functionality and should be read as inspiration.
Knock is a minimal API authentication setup with no bells and whistles.
Devise has a lot of bells and whistles.
Credible wants to be somewhere between these two, offering an API authentication solution with some bells and whistles like:
...and a bunch of authentication strategies like:
Note also: Common practise now is to have an Auth Server and a Resource Server. Credible is setup in such manner that it can be authentication on both ends.
A typical auth server might provide:
...whereas any of these will provide an Access Token used for this sole authentication strategy on the resource server:
Right? ... Yeah, I think so.
Credible already supports Password, Confirmation, Invitation... and now also refresh tokens. Oh and access token auth, of course (because it plays both sides). I just have this question: Should it?
Should it, or should Credible be separated into, say, Credible::Auth and Credible::Resource or something like that?
Answer: No. Too much fragmentation for such a small concern. Credible should contain all strategies. There is maybe an argument that resource-server authentication could be extracted into a sub-dependency, maybe "credible-lite" or "credible-access" or something like that. But no more messy fragmentation than that should occur, certainly.
Anyway, inspirations...
I just wanted to list them here so that ideas can be discussed. They should also be linked to as alternatives in the main README.