Doorkeeper: Preventing user login after POST /oauth/token

Created on 4 Sep 2014  路  5Comments  路  Source: doorkeeper-gem/doorkeeper

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?

Most helpful comment

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.

All 5 comments

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!

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

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

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

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.

Was this page helpful?
0 / 5 - 0 ratings