Best way to renew token?

[dpakatheman]

What is the best way to renew the token?

I was able to use LambdAuth in my own sample application, but I need to enter my password every 15 minutes to get a new token if I want to continue using the application after that time period. The sample application only performs a single operation with a successful login, so it doesn't seem to address this issue.

I want to replicate the behavior of most secure applications, like a bank web page, allowing continuous usage, but automatically logging the user out after a period of inactivity.

Am I correct in assuming that I would need to write a new function, similar to LambdAuthLogin, but it would require an authenticated user with a valid token, and it would return a new token with an extended duration? Then my application would make sure to call that function and change the token before the existing token expires?

Am I missing an easier solution? Are there security implications to my suggested implementation, or a better approach?

[mazurio]

I am also interested.

[stephencroberts]

You can pass token duration to the call to getOpenIdTokenForDeveloperIdentity and store the token as a cookie which could be used to keep the user logged in for long periods of time, even across browser sessions.

If you're building a SPA, to keep the user from being "logged out" during an active session, maybe you could just cache their credentials and re-authenticate? You definitely wouldn't want to store the credentials as a cookie or in local storage, but it should be safe enough to store in memory in your app. If the user refreshes the browser, the credentials will be gone.

[mazurio]

Looks like getOpenIdTokenForDeveloperIdentity token lifetime is maximum 24h, I was thinking about storing email password (encrypted locally in database) and re-authenticate in the background - if the credentials fail (e.g. password has been changed on another device) then user is logged out.

Does anyone have better ideas?

[scottgeye]

My current thinking is to create a new sessions table to keep track of logins along with generating a refresh token that gets returned to the user on successful login and gets stored in the new table. That way the client can cache the refresh token locally and call a refresh lambda function whenever the old token has expired to run through the same getOpenIdTokenForDeveloperIdentity as the login function and return a new valid token. That way as long as the client has the refresh token, they can continue to make calls and the client can force a logout and destroy their session or we can invalidate the session in db by removing the item in the sessions table.

[rogusdev]

I am also curious about the author's and contributors' thoughts on this. My own thought is that the login script ought to include 2 additional steps: 1) generate a session token with an expiration date (1 hr, 1 year, whatever: configurable, ideally set by some argument passed to the login method, and only create if such an expiration argument is passed) that is stored hashed in a new table in dynamodb (so there can be more than one session token per email -- this is so each token is unique per browser, not user/email/identity) and returned in the successful login response after an email + password login, and then 2) include a new method to login with an email and session token -- instead of password, thus why it should be stored hashed in the db as it is password equivalent, just not created by the user. This way you can store a session locally in the browser without storing their password by storing the email and session token.

There would then also need to be an additional lambda script to remove either one session token for a given email address (and verify it), or all session tokens for a given email / identity. This would allow users to clear any tokens on lost devices/whatever.

[stephencroberts]

If you haven't heard: https://aws.amazon.com/blogs/aws/new-user-pools-for-amazon-cognito/. I'm doing some testing with it now. It's a beta product, but hopefully they'll move quickly. It's been great to work with so far.

[tomasgriffin]

My current thinking is to create a new sessions table to keep track of logins along with generating a refresh token that gets returned to the user on successful login and gets stored in the new table.

@scottgeye did you ever get round to implementing this? This sounds like the optimal solution to this problem. As others are commenting, it looks like the maximum token lifetime you can set when calling GetOpenIdTokenForDeveloperIdentity is 24 hours, after which the user will need to login again.

@stephencroberts and @mazurio's suggestions of caching the username and password locally and re-authenticating when the token expires do solve this problem but feel insecure.

[scottgeye]

@tomasgriffin, I did end up doing an implementation, but it's a little heavy and a way too integrated into the rest of an old project for me to separate out.

I'd actually recommend checking out cognito user pools. This wasn't around when I was building my auth, but looks like a much better solution than rolling your own and integrates nicely with lambda and the rest of AWS APIs.

[stephencroberts]

@tomasgriffin, I agree with @scottgeye -- I abandoned rolling my own auth in favor of cognito user pools.