Openiddict-core: For the Implicit flow, is the user supposed to reenter their credentials whenever the access token expires?

Created on 4 Dec 2017 · 6Comments · Source: openiddict/openiddict-core

From what I understand, the end-result of the implicit flow is the access token, which allows the client (in my case a JS SPA) to authenticate into resource servers (APIs).

The access token is usually only valid for ~1 hour, then it expires - making it useless.

What should my JS app do then? Redirecting the user back to the auth server is unrealistic since then the user will have to reenter their credentials every 1 hour!

I also know that the implicit flow doesn't support refresh tokens so I can't use those either.

Is there a way to persist the user's login? How do things like Facebook keep you logged-in indefinitely?

question

Source

Biarity

All 6 comments

What should my JS app do then?

When the initial access token expires, the JS app can send a prompt=none authorization request (in a hidden iframe so it's invisible for the user).

This mechanism is used in the implicit flow sample:

Depending on the JS client you use, this can be done automatically: https://github.com/openiddict/openiddict-samples/blob/dev/samples/ImplicitFlow/AureliaApp/src/open-id-connect-configuration.ts#L13

kevinchalet on 4 Dec 2017

Thanks, I'll have a read at those.

I'm assuming that with this method, if the user doesn't have the JS client open for longer than 1 hour (or whatever expiry), then they'll have to re-enter their credentials, right?

If so, how do you feel about never-expiring access tokens? I know they can be a huge SPOF, but would you say that that's still relevant in apps where convince is more important?

Biarity on 4 Dec 2017

I'm assuming that with this method, if the user doesn't have the JS client open for longer than 1 hour (or whatever expiry), then they'll have to re-enter their credentials, right?

No, users won't have to re-enter their credentials as long as their server-side session (represented by the ASP.NET Core authentication cookie) is valid. If the server-side session is expired, the prompt=none request will fail and the JS client will have to do a regular request.

If so, how do you feel about never-expiring access tokens? I know they can be a huge SPOF, but would you say that that's still relevant in apps where convince is more important?

That's not ideal, specially if you can't revoke your tokens.

kevinchalet on 4 Dec 2017

❤1

Thanks heaps, I think I got it. Any idea why the request with prompt=none has to be done in an iframe? Can't I do this with AJAX and follow redirects?

Also, how long do ASP.NET Core cookie sessions last?

Biarity on 5 Dec 2017

@Biarity you can configure cookie expiration with service.ConfigureApplicationCookie