Roadmap for 1.0

[matfiz]

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.

1. 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)

2. Improve error reporting

• pass error message to final response from doorkeeper (Allow user to raise authorization error with a custom message doorkeeper#749)

3. Improve test coverage

Do you have anything else to add?

[NuckChorris]

I'm pretty sure a lot of these depend on the following:

• Upgrade to use Add registration for grant flows doorkeeper#733 when it's merged
• Actually follow the RFC

[NuckChorris]

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

[ebosantos]

If we could address the three mentioned features, it'd be a great progress.

[matfiz]

I have added examples in the wiki: https://github.com/doorkeeper-gem/doorkeeper-grants_assertion/wiki. Comments welcomed

[NuckChorris]

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

[MarkMurphy]

Would love to see some movement on this

[dsantosmerino]

Me too. @matfiz do you have more ideas to improve the gem?

[matfiz]

@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.

[johnschult]

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.

[nbulaj]

Any PRs are welcome :) @johnschult

[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.

[matfiz]

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!

[nbulaj]

Hi @matfiz , hope you're well! Could we release 0.3 with latest changes to rubygems? Unfortunately I don't have permissions for that 😞

[nbulaj]

Or maybe @tute could give me such permissions for RubyGems, I see you as the owner of the gem

[tute]

Send me your email at RubyGems Nikita, and I'll do it.

[tute]

All done!