search

socialcast / devise_oauth2_providable

Rails3 engine integrating OAuth2 authentication with Devise
MIT License
219 stars 102 forks source link

Access permission not saved. Bug or missing feature? #19

Closed ZenCocoon closed 12 years ago

ZenCocoon commented 12 years ago

As of now, it seems that the provider will not save the access permission, therefore, on each "Sign In" the user will have to accept or deny access.

How to save such authorization in case of acceptance ? Is that a bug or a feature that need to be implemented on top of it ?

Thanks in advance for your enlightenment, Best regards,

ZenCocoon commented 12 years ago

I've setup a demo app that can help better understand what I mean : https://github.com/ZenCocoon/testoauth2provider

wireframe commented 12 years ago

I am 100% on board with adding this as a feature. If you have any thoughts on how to best support this, please let me know!

ZenCocoon commented 12 years ago

Thanks for your reply, I'll dig through and see how I would see that best.

ZenCocoon commented 12 years ago

What would you think about a "Connection" relation, linking User (Devise resource) to Client ? That seem to be the way used by GitHub and feels clean to me.

wireframe commented 12 years ago

i've been reviewing the oauth2 spec a lot and it seems like this is only an issue with the implicit grant_type flow.

if you use the authorization_code grant_type flow, you exchange your authorization code for an access token and a refresh token as well. So you don't need to re-authorize the user since you can fetch a new access token via the refresh token.

are you using the implicit flow in your app?

ZenCocoon commented 12 years ago

Sorry for the late reply. That makes sense, thanks for the pointer.

I'll dig OmniAuth 1.0 again to see how to rely on the authorization_code grant_type flow. I should be using the implicit grant_type flow so far.