ESS timeout after 5 minutes

1

Hello all,

I’m working with the inrupt solid server alpha bots code and am running into an issue. Every so often I am trying to save data to a specific resources, and this works until about 5 minutes when the server times out with a 401 unauthorized error. This occurs with every operation, so I am wondering if there is something Inrupt’s servers that expires a connection every 5 minutes or so?

Thanks in advance

2

Hey Gaz

Yes, I guess the access token has an expiry of 5 minutes. You can check it by inspecting the access token, eg putting it in jwt.io. Do you use any library for authentication, if yes which and how? If you build it yourself, you likely need to use the refresh token to obtain a new access token (see eg the TokenRefresher.ts class in solid-client-authn-js. This is related to the answer from @zwifi in the other thread.

3

Hello A_A,

I used the static client credentials authentication provided by Inrupt. My understanding of zwifi’s answer was the refresh token flow was deprecated, unless I misunderstood? I didn’t do anything extra except register the session with the static credentials from the Inrupt servers and used the node js solid-client-authn library.

4

So I guess you use this?

const session = new Session();
session.login({
  // 2. Use the authenticated credentials to log in the session.
  clientId: myClientId,
  clientSecret: myClientSecret,
  oidcIssuer: 'https://login.inrupt.com'
}).then(() => {
  if (session.info.isLoggedIn) {
    // 3. Your session should now be logged in, and able to make authenticated requests.
    session
      // You can change the fetched URL to a private resource, such as your Pod root.
      .fetch(session.info.webId)
      .then((response) => {
        return response.text();
      })
      .then(console.log);
  }
});

If yes, it sounds like a library bug to me if it doesn’t automatically refresh, so you may open an issue in their github repository.

I think the library API is deprecated, using refresh tokens without the library not.

And a bit offtopic, if you provide more concrete information in the question, I’d need to guess less stuff about what you did which makes it easier to help. Imo this article from stackoverflow is very useful, both for understanding the problem better and then asking easy-to-answer questions: How to create a Minimal, Reproducible Example - Help Center - Stack Overflow

5

Hi @gaz009 , @A_A . There are a couple of things relevant to the conversation here:

  • first, regarding my previous answer on the refresh flow: I’m sorry I wasn’t clear, what is deprecated is using the refresh token as a way to log a backend script in, not the use of the refresh token in general. Our libraries do support the refresh token flow when it is applicable.
  • that brings me to my second point: the refresh flow isn’t applicable in the case of the client credential flow, used by statically registered clients. Therefore, what you are experiencing is expected behavior.

To be specific, the ESS OpenID Provider doesn’t issue a refresh token as part of the response to the token endpoint request sent by a statically registered client using the client credentials flow. There is a rationale for this: the refresh token’s purpose is to allow a client to refresh an access token without requiring the resource owner being present. In the case of the client credentials flow, the resource owner and the client are one, so the resource owner is literally never not present when the client is running. Therefore, it is possible to simply log the session back on expiration, using the same client id and secret.

As a matter of fact, the latest release of solid-client-authn, Release v1.14.0 · inrupt/solid-client-authn-js · GitHub, makes it easier to implement precisely this behavior. Namely, you can do something like

const session = new Session();
session.events.on(EVENTS.SESSION_EXPIRATION, () => {session.login(...)});
await session.login(...)

Passing your clients id and secret to both calls to session.login. This should result in the session logging back in when it expires, without a refresh token being necessary. Forgive the lack of details in the example, I don’t have access to my computer and typing code for mobile isn’t that fun ^^.

I hope this helps, let me know if you have any follow up questions.

2 Likes
6

Thanks for the answer @zwifi

Out of curiousity: Is there a reason this procedure is not automatic? What I mean is, that for the browser login the library automatically uses the refresh token to stay logged in, even if the access token expires. What is preventing the same for client credentials? Maybe the security concern of storing these credentials?

And I think it would be helpful to add a warning box or similar to the documentation, saying that tokens expire after some time and you have to manually keep yourself logged in with client credentials. At least I couldn’t find such an info while reading the documentation.

7

Thanks for the help @zwifi I updated my code to properly handle the refresh instance now.