# AuthClient Update - Idle Timeouts

**URL:** <https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464>\
**Category:** JavaScript\
**Tags:** Discussing\
**Created:** [January 24, 2022, 7:41pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464 "2022-01-24T19:41:12Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [January 24, 2022, 7:41pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/1 "2022-01-24T19:41:12Z")

</div>

The Dfinity security team has flagged the 24 hour default delegation in `@dfinity/auth-client` as too insecure of a default, so we will be releasing an update as an `0.11.x` minor version update.

The new version will have some changes to `@dfinity/agent` as well as the auth-client:

- Set the default delegation timeout to **8 hours**
- Add support for invalidating an identity to an `Actor` and `HttpAgent`
- Add an `idle` tracker to the `auth-client` that will invalidate
- Provide `onIdle` and `onIdleWarning` callbacks to the authClient to trigger warning dialogs and prompts to refresh the user’s authentication
- Default idle time will be **10 minutes**
  - After `Idle`, the user’s identity will be invalidated, and the delegation will be cleared from localStorage

- Delegation timeout, idle time, and idle warning will all be configurable

These features are designed to make IC dapps secure by default, and hopefully with enough configuration to suit a variety of use cases, while minimizing the impact to user experience that is provided by our default.

What do you think? Do you support these changes, and are the defaults sensible for your use cases?

---

<div class="post-metadata">

**Author:** ![Gabriel](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gabriel/32/546_2.png) [@Gabriel](https://forum.dfinity.org/u/Gabriel)\
**Post date:** [January 24, 2022, 7:50pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/2 "2022-01-24T19:50:42Z")

</div>

Nice, I love this one:

`Provide onIdle and onIdleWarning callbacks to the authClient to trigger warning dialogs and prompts to refresh the user’s authentication`

Question, that default idle time is the one you can set in `maxTimeToLive` ?

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [January 24, 2022, 9:10pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/3 "2022-01-24T21:10:14Z")

</div>

The current `maxTimeToLive` option represents the expiration of the delegation, which becomes invalid after that # of nanoseconds. In the new scheme, it will represent the amount of time before a `DelegationIdentity` becomes invalid, assuming you have either prevented your browser from going idle in that time, or if the application has set the idle time to equal the `maxTimeToLive`, because they are not interested in that behavior

---

<div class="post-metadata">

**Author:** ![infu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/infu/32/11321_2.png) [@infu](https://forum.dfinity.org/u/infu)\
**Post date:** [January 30, 2022, 1:07pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/4 "2022-01-30T13:07:25Z")

</div>

Sounds good. I would also like to check if delegation has expired and not rely on catching errors when calling actor functions. Is that included in the list? Maybe both - timeout and idle are triggering the onIdle callback?

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [January 31, 2022, 5:40pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/5 "2022-01-31T17:40:12Z")

</div>

We have a utility for that! `@dfinity/authentication/isDelegationValid`

> **[@dfinity/authentication](https://erxue-5aaaa-aaaab-qaagq-cai.raw.ic0.app/authentication/modules.html#isdelegationvalid)**
>
> Documentation for @dfinity/authentication

---

<div class="post-metadata">

**Author:** ![infu](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/infu/32/11321_2.png) [@infu](https://forum.dfinity.org/u/infu)\
**Post date:** [February 1, 2022, 11:44am UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/6 "2022-02-01T11:44:48Z")

</div>

Nice, however the only place I have seen it used is here [agent-js/index.ts at 96c5fee3f8e8246960f6cd4031ca52eb4dc6bd85 · dfinity/agent-js · GitHub](https://github.com/dfinity/agent-js/blob/96c5fee3f8e8246960f6cd4031ca52eb4dc6bd85/packages/auth-client/src/index.ts#L186)

I thought there will be something like agent.isExpired(), because it seems that currently, we have to take a delegation from localStorage to use this function. If I hardcode the key “ic-delegation” things may break in the future.

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [February 1, 2022, 4:24pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/7 "2022-02-01T16:24:29Z")

</div>

I see what you mean - I’ll make a note to add the ability to inspect the identity being used by an actor, as well as checking its expiration, during the invalidation refactor

---

<div class="post-metadata">

**Author:** ![Nakamotik](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nakamotik/32/3530_2.png) [@Nakamotik](https://forum.dfinity.org/u/Nakamotik)\
**Post date:** [February 9, 2022, 3:05pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/8 "2022-02-09T15:05:23Z")

</div>

Is “idle time” the time when there are no requests to IC with user delegation?  
What does “refresh the user’s authentication” mean?

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [February 9, 2022, 3:49pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/9 "2022-02-09T15:49:32Z")

</div>

Idle time is when there is no cursor movement, scrolling, or keyboard events for a certain amount of time.

Refreshing the authentication would require sending the user back to II to log in again, but it would allow you to replace the `Identity` inside of the `HttpAgent` without having to re-initialize the `Actor`

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [March 24, 2022, 11:22pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/10 "2022-03-24T23:22:58Z")

</div>

Getting close to the final shape of this API - here’s a glimpse into what it will look like

```auto
const authClient = await AuthClient.create({
  idleOptions: {
    idleTimeout: 1000 * 60 * 30, // default is 30 minutes
    onIdle: () => {
      // invalidate identity in your actor
      Actor.agentOf(actor).invalidateIdentity() 
      // prompt user to refresh their authentication
      refreshLogin();
    },
    disableIdle: false, // set to true to disable idle timeout
  }
});
// ...authClient.login()
const identity = await authClient.getIdentity();
const actor = Actor.createActor(idlFactory, {
  agent: new HttpAgent({
    identity,
  }),
  canisterId,
});

refreshLogin() {
  // prompt the user before refreshing their authentication
  authClient.login({
    onSuccess: async () => {
      // authClient now has an identity
      const identity = await authClient.getIdentity();
      // set new identity in your actor without reloading the page
      Actor.agentOf(actor).replaceIdentity(identity);
    },
  });
}

```

---

<div class="post-metadata">

**Author:** ![peterparker](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@peterparker](https://forum.dfinity.org/u/peterparker)\
**Post date:** [March 25, 2022, 6:39am UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/11 "2022-03-25T06:39:48Z")

</div>

Nice 👍

- will `onIdle` callback accept promises too?

- if the identity becomes idle and `Actor.agentOf(actor).invalidateIdentity()` would not be called - i.e. if a developer does not implement such call, what would or would not happen?

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [March 25, 2022, 9:59pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/12 "2022-03-25T21:59:01Z")

</div>

Okay, I have a better pattern now. The `authClient` can let you register Actors. Registered actors will automatically get their identity invalidated after idle, and can get refreshed after `login` success.

You can add additional callbacks with `authClient.idleManager?.registerCallback?.(cb)`

```auto
const authClient = await AuthClient.create({
  idleOptions: {
    idleTimeout: 1000 * 60 * 30, // default is 30 minutes
    disableIdle: false, // set to true to disable idle timeout
  }
});
// ...authClient.login()
const identity = await authClient.getIdentity();
const actor = Actor.createActor(idlFactory, {
  agent: new HttpAgent({
    identity,
  }),
  canisterId,
});

authClient.registerActor("ii", actor);

refreshLogin() {
  // prompt the user then refresh their authentication
  authClient.login();
}

authClient.idleManager?.registerCallback?.(refreshLogin)

```

---

<div class="post-metadata">

**Author:** ![saikatdas0790](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/saikatdas0790/32/17147_2.png) [@saikatdas0790](https://forum.dfinity.org/u/saikatdas0790)\
**Post date:** [June 8, 2022, 3:20pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/13 "2022-06-08T15:20:15Z")

</div>

@anon74414410

Could we do away with the `onSuccess` callback inside the `authclient.login` and just resolve the promise with the relevant response (`Identity`?) instead of having to specify a callback.  
This is because the `login` is itself a Promise and it seems like a poorly designed API if we need to specify a callback inside it when everything’s resolved.

Thoughts?

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [June 28, 2022, 7:12pm UTC](https://forum.dfinity.org/t/authclient-update-idle-timeouts/10464/14 "2022-06-28T19:12:41Z")

</div>

The `login` being a promise is mainly to support `async / await` patterns inside of the `onSuccess` callback. A callback approach is appropriate here because it mirrors the actual browser API being used. Because we have to handle interruptions from the opened window, and we are relying on the `message` event listener, which are asynchronous and event-based.

I get that trying to await the result of the operation is syntactically nice, but it can also lock up the user’s interaction in the page that initiated the request, which is not ideal. You are free to do this by wrapping the `login` and having the `onSuccess` resolve that `Promise`, but it is not an ideal practice that I would encourage