Auth provider cleanup #6
Conversation
…lResponseParameters population removed on TokenRequest procession
…ference to context property confusing
… to RefreshTokenProvider
…ions per single client/user combination
| // TODO: log suspicious activity | ||
| return; | ||
| } | ||
| var user = _repo.FindUserByName(refreshToken.UserName); |
There was a problem hiding this comment.
I'm trying to understand this one. You load a refresh token by the hashed token id. Then you load the user by the user name of this token. What is the benefit of this approach? The comment "Refresh token was issued for the other user" doesn't make sense to me. Can you pls explain what your intention was? Thx!
There was a problem hiding this comment.
Hi @VILLAN3LL3 ,
Well it's been very long time since I looked in this code so can't guarantee that everything is correct.
From what I see and as far as I remember refresh token hash is the only thing which is required to authorize the user and issue a fresh access token.
So the only way to know for which user to issue a new access token is to keep user name associated to refresh token. The code in line 78 looks up the user in the database and check in the line 79 is redundant if you never delete users. I guess I put it there just to avoid resharper warning further down.
So bottom line the comment below is misleading. If we actually end up in the line 83 it means that the user, for whom the token was issued - now doesn't exist in the database.
Hope that helps
Sorry for a messy pull request, it's my first time :) Will try to break down the major changes I made here:
AuthenticationTicketProviderand reused in bothSimpleAuthorizationServerProviderandSimpleRefreshTokenProvider. This was done because of: a) security reasons (ProtectedTicketwas actually a validaccess_tokenthat could be reaused to access resource server); b) allowing changes in machineKey without any necessity to update database.SessionIdcolumn added toRefreshTokenentity which is generated per each password grant flow. Previously it was impossible to keep user logged in with refresh token on 2 different machines or 2 different browsers simultaneously, now every time user enters credentials a separate record with uniqueSessionIdwould be created inRefreshTokenstable without affecting other sessions.Owin.Corsmiddlware. This allows to handleOPTIONSrequest correnctly. Previously they would be rejected byOwin.OAuthmiddleware.