2

my system is composed of several entities

  • IS - an identity provider (Identity Server 4)
  • C - an hybrid client with refresh_token

  • EP - OAuth 2.0 external provider

    1. When a user tries to log in C, he is redirected to IS

    2. Once in IS, he presses EP and sign in with his credentials

    3. using EP_code_grant, the IS can get an EP_access_token+EP_refresh_token

    4. upon getting and parsing these, IS now trusts the user and generates a pair IS_access_token+IS_refresh_token so the user can access client C

So far, so good

my problem is when the EP entity disables the user on his system, my user will still be logged for IS_access_token lifetime and will use IS_refresh_token to generate new IS_access_tokens. therefore, potentially, the user will never be logged out from the system (only when refresh_token expires... and that can be for a long time)

Any suggestions?

My current idea is to store the EP_access_token+EP_refresh_token in a custom cookie, and before using IS_refresh_token, get a new EP_access_token+EP_refresh_token using EP_refresh_token, therefore, if the EP can actually emit a new EP_access_token+EP_refresh_token then it is safe to generate a new IS_access_token+IS_refresh_token using IS_refresh_token

If this is possible, how can I do this in Identity Server 4?

Thanks in advance

Alexandre Costa
  • 318
  • 3
  • 16
  • First of all - are you sure that your client is Implicit? According to the official documentation http://docs.identityserver.io/en/release/topics/refresh_tokens.html, this is not quite possible. – m3n7alsnak3 Mar 22 '18 at 15:18
  • you are quite right, client grant type is hybrid, but that is beyond the point and i am currently using refresh tokens – Alexandre Costa Mar 22 '18 at 15:34
  • Yes, correct. So your problem is the cookie life time. I guess that when you close and open the browser the problem is gone (your user is forced to login again). What do you mean by `EP entity disables the user on his system`? And admin deleting/lowering the permissions of a user? – m3n7alsnak3 Mar 22 '18 at 17:34
  • Not quite. Let us say EP is google. If a user uses Google to sign in on my system, everything is fine. Then, a while later, the user deletes the google account, therefore, he cannot request more tokens to google (EP). Eventually, the access_token for my system turns invalid (lifetime), and I use my refresh token to get a new pair. Doing this does not require to go to Google, so my system generates a new pair. What I want is, when generating this new pair, I should also verify that the user exists and is valid to get tokens in Google (EP). Hope it clarifies a bit – Alexandre Costa Mar 22 '18 at 17:42
  • OK this really got my interest. According to the docs (http://docs.identityserver.io/en/release/topics/signout_federated.html) this is already implemented on the Identity Server side, so all that you need to do is to configure your **EP** and also it should support this functionality. – m3n7alsnak3 Mar 22 '18 at 18:51

0 Answers0