3

I am trying to use AWS Cognito user pools with Cognito federation as auth for my APIs on api-gateway. I got the authentication & authorization part (using roles) to work, but now stuck on how to revoke access. After login & getting the federated identity, I deleted the identity from identity browser (console) & deleted the user from cognito user pool. But that does not invalidate access using the earlier generated tokens, till they expire (which is a minimum of 1 hour).

I also tried setting ServerSideTokenCheck to true, but that doesn't work either. The only way to "revoke" access seems to be this. But this does not work for us as our use case assigns roles to a group. I cannot have groups of users lose access to revoke/deny access to one user.

Is there anything I have missed to get this done? I cannot fathom an auth service which does not give me easy way to revoke access to user.

asr9
  • 2,440
  • 1
  • 21
  • 37

2 Answers2

3

This is a common case with stateless JWT tokens issued with Cognito for authentication.

Once a user got hold of a token which valid for 1 hour, the token itself acts as the proof for authentication. The token is signed and issued by AWS and for validation it only requires to do a signature verification using a publickey.

The approach you can handle this is at the authorization layer in your application where you can check either the user is active/deactive in your database after the user successfully authenticates. You can further delete the user from Cognito where he is not able to login back again.

Ashan
  • 18,898
  • 4
  • 47
  • 67
2

I see what you are saying and as the other answer explained when the token is issued, the user can use the token until its expiry date. A solution to your problem can be handled two ways:

Cognito way: For this, you make two calls to Cognito, first if the user is enabled, second if so, authenticate its token.

DB way: You have a DB, which act as a "black list" holder, so when you want to disbale the user, the app, adds the username of the user to the DB. Therefore, when the user wants to authenticate, you first check with the DB (if the user is enabled), then check its cookie for authentication/authorization.

Note: If your user base is small, you could go the Cognito way, however there is a limit to Cognito calls, if you have a large user base; you should consider the second approach.

o-0
  • 1,713
  • 14
  • 29