Roadmap for 1.0
matfiz opened this issue · 16 comments
As @tute has stated, this gem will be released to RubyGems once it reaches it's 1.0 version. I think it is a good idea to state clearly the roadmap, i.e. what is missing and on what we should focus the development.
- Improve documentation for implementing authentication against most common 3rd party OAuth2 providers (https://tools.ietf.org/html/rfc6749#section-4.5)
- add example for utilizing Facebook login
- add example for utilizing Google login (CrossClient Auth)
- Improve error reporting
- pass error message to final response from doorkeeper (doorkeeper-gem/doorkeeper#749)
- Improve test coverage
Do you have anything else to add?
I'm pretty sure a lot of these depend on the following:
- Upgrade to use doorkeeper-gem/doorkeeper#733 when it's merged
- Actually follow the RFC
One thing I've been thinking is how much abstraction this should offer, should we be providing an OmniAuth-style strategies for verification or just bare metal "hand you the token" stuff? Or potentially some combo? Token verification is a pretty big task, and it'd be nice to have it separated at least from finding a user
If we could address the three mentioned features, it'd be a great progress.
I have added examples in the wiki: https://github.com/doorkeeper-gem/doorkeeper-grants_assertion/wiki. Comments welcomed
It's been a while since I read the spec but it seemed to me like we were supposed to use a separate uri for each provider, not pass the provider in as a param. That's why I've been waiting for Doorkeeper to add a strategy registration system for this iirc
Would love to see some movement on this
Me too. @matfiz do you have more ideas to improve the gem?
@dsantosmerino Basically, we are a little bit stuck here. The major problem is we are not following the RFC. There were some movements towards supporting the grant flow in a correct way (see: doorkeeper-gem/doorkeeper#733) and the last comment here: #9, but it never made to doorkeeper. If you have time, I am willing to help you to get it done.
Knock knock! 😄 So, I came across this while trying to figure out how we might add a custom grant type to doorkeeper. We have a SMS grant type that is a variation of authorization code and resource owner password credentials. Is this still dead in the water? We are fairly motivated to make it work.
Any PRs are welcome :) @johnschult
Yeah I get that 😉 I suppose we need to figure out where the "problem" is. From what I gather, it is not sufficient to have the grant type be "assertion" when the correct grant type should be something like urn:ietf:params:oauth:<value>. Is that the whole issue? Forgive my ignorance, I just stumbled on doorkeeper and am trying to figure out if it is a path we want to go down. We have a fairly non-standard OAuth 2.0 authorization server we have implemented that needs some TLC. I think much of what we need can be done with doorkeeper, but the custom grant type would be a bit of a stumbling block.
You're correct @johnschult! The problem is that we need to support the correct URN in doorkeeper gem. Can you provide a comment it this issue #9 ? It would be great to push things forward!
Hi @matfiz , hope you're well! Could we release 0.3 with latest changes to rubygems? Unfortunately I don't have permissions for that 😞
Or maybe @tute could give me such permissions for RubyGems, I see you as the owner of the gem
Send me your email at RubyGems Nikita, and I'll do it.
All done!