Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preventing user login after POST /oauth/token #475

Closed
beweinreich opened this issue Sep 4, 2014 · 5 comments
Closed

Preventing user login after POST /oauth/token #475

beweinreich opened this issue Sep 4, 2014 · 5 comments

Comments

@beweinreich
Copy link

I'm using devise + doorkeeper for my web app / API.

After I send a POST to /oauth/token for a user, it generates a token and token type as expected. However, it also creates a session for the user and logs them in. Is there a way to prevent this?

I only want to authenticate the user, generate a token that can be used for authorization in the future, not create a session.


Why is this a problem for me (and possibly others)?
Suppose I have an endpoint like /api/v1/users/me

 def me 
      User.find(doorkeeper_token.resource_owner_id) if doorkeeper_token
 end

This always returns the current session user, not the current user based on the access token I sent.

Perhaps, the more appropriate way to handle this is to ignore the session data in the API layer?

@tute
Copy link
Contributor

tute commented Sep 6, 2014

It seems very specific to your application rather than with doorkeeper itself.

I'd assume you are using a sign_in helper somewhere in your up, which tells devise to create a session, but it's hard to tell.

I'd suggest you ask about it in
http://stackoverflow.com/questions/tagged/doorkeeper, which will get attention from more people than in this issue tracker. Thank you!

@tute tute closed this as completed Sep 6, 2014
@kennyevil
Copy link

I had a similar problem. Implementing the resource_owner_from_credentials method as suggested in the wiki seemed to be causing the users authenticated this way to remain logged in on the server. This had the extra issue of causing Doorkeeper to issue tokens to those logged in users when it was supplied with crappy email/password combinations (eg with misspelled password). I found that putting this in the method solved that issue. If someone thinks I've done this wrong and wants to correct my work, please do.

resource_owner_from_credentials do |routes|
    request.params[:user] = {:email => request.params[:email], :password => request.params[:password]}
    request.env["devise.allow_params_authentication"] = true
    user = request.env["warden"].authenticate!(:scope => :user)
    request.env["warden"].logout
    user
end

@tute
Copy link
Contributor

tute commented Jun 3, 2015

Thanks @kennyevil. I just added a note in the wiki linking to this issue in case the suggested implementation is buggy.

@avitus
Copy link

avitus commented Sep 25, 2015

@kennyevil Yes, this change was necessary for me too. Not logging out the user resulted in associating the next token with the previous user and caused no end of mysterious problems.

@stevenharman
Copy link
Contributor

stevenharman commented Jun 1, 2017

I'm currently looking into Doorkeeper + Devise for the Password Grant flow, and came across this issue (by way of the Wiki page). The problem seems to be that the suggested implementation stores a user in session. Since this is all for a token-based authentication strategy, it seems to me we'd NOT want to ever store the user in session. Warden has a mechanism built in just for this by way of store: false.

# change this:
request.env["warden"].authenticate!(scope: :user)

# to this:
request.env["warden"].authenticate!(scope: :user, store: false)

And Warden will NOT store the user in the session. Perhaps someone who's seen the mentioned problem can comment as to whether or not that works. And if so, I'd be happy to update the Wiki accordingly.

UPDATE: I'm updated the wiki page to include the store: false bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants