doorkeeper-grants_assertion
doorkeeper-grants_assertion copied to clipboard
doorkeeper-gem
Roadmap for 1.0
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)
- [x] add example for utilizing Facebook login
- [x] add example for utilizing Google login (CrossClient Auth)
- Improve error reporting
- [ ] pass error message to final response from doorkeeper (https://github.com/doorkeeper-gem/doorkeeper/pull/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
@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: https://github.com/doorkeeper-gem/doorkeeper/pull/733) and the last comment here: https://github.com/doorkeeper-gem/doorkeeper-grants_assertion/issues/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.
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 https://github.com/doorkeeper-gem/doorkeeper-grants_assertion/issues/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 :disappointed:
Or maybe @tute could give me such permissions for RubyGems, I see you as the owner of the gem
