Openiddict beta: OpenIddictUser no more present

[Myrmex]

Hi, I'm trying to create a WebAPI project based on this example, by creating a new ASP.NET Core Web API app and following the code. Anyway, it seems that the OpenIddictUser class is no more present in the current version of Openiddict which gets restored: the version is beta1 0467 at the time of writing.

[kevinchalet]

@Myrmex FYI, you can now find a password flow sample in the openiddict-samples repo: https://github.com/openiddict/openiddict-samples/tree/master/samples/PasswordFlow

[Myrmex]

Thanks, that's great material, but correct me if I'm wrong: the PasswordFlow sample you pointed me to does not use JWT tokens, does it? I'm trying to implement an Angular2 web app on the client side, consuming a .NET Core WebAPI on the server side, securing the API methods using JWT tokens in my HTTP requests (implemented with the Angular2 JWT AuthHttp wrapper).

[kevinchalet]

Indeed, all the "official" samples use the default token format (which provides both integrity and confidentiality, since it relies on authenticated encryption).

That said, the access token format is supposed to be completely opaque to clients, so if your JS library relies on the fact your access tokens are JWTs, then it's doing it completely wrong and you should consider using another one 😄

[jdosullivan]

Continuing off this topic since it's still open. One thing I don't understand.

In my previous apps I've always decoded the token client side to check if it's expired before sending a request to the server that required a valid token. What is the recommended way to do this now since we can't decrypt the token in the default format.

Am I to send a request to a protected endpoint and respond to a token invalid/expired response?

If so that doesn't seem like a scalable strategy at all.

[kevinchalet]

@jdosullivan when returning an access token, OpenIddict also returns an expires_in property, that contains the remaining token lifetime (in seconds).

You can read https://tools.ietf.org/html/rfc6749#section-5.1 for more information.

[jdosullivan]

Is there a way to get the exact time of expiration or at least return the date created as well.

The time left for expiration isn't really useful unless I know the time of creation.

[kevinchalet]

I know the time of creation

You know it: it's when you receive the token response.

[jdosullivan]

Well in the future if you decide to add the exact creation time of the token I would be happy.

I am worried I might be off by milliseconds or a few seconds (at worst) depending on the latency of my api server returning the token. Right now I pad the creation time by a few seconds to account for this but it feels hacky.

I can imagine pulling my hair out if my creation time is off by a few milliseconds and I try to issue a request at just the right time.

But thanks for the confirmation. Your library is much appreciated!

[kevinchalet]

Well in the future if you decide to add the exact creation time of the token I would be happy.

The OAuth2 spec doesn't have a property for that, so it would be necessarily non-standard. I'm not saying this won't happen, but I try to keep OpenIddict as close to the spec' as possible.

I am worried I might be off by milliseconds or a few seconds (at worst) depending on the latency of my api server returning the token.

The same thing happens when you resolve the exp property from a JWT token if the server clock and the client clocks are not perfectly synchronized (it's even worse, IMHO, because you compare dates from 2 different sources).

Right now I pad the creation time by a few seconds to account for this but it feels hacky.

Why do you think it's hacky? It's super common to consider a token unusable 1~5 minutes before it's really expired to account for clock desynchronization.

[Bartmax]

@jdosullivan

Well in the future if you decide to add the exact creation time of the token I would be happy.

I don't think this will do any good but provide a false sense of sync.

If you have the exact time the token expires, and you send a request few ms before it expires, the latency on the authorization server will still play a big role here and may reject the request depending on how much time it takes to validate. Having the exact date a token expires is not guarantee at all that the request will succeed.

What OpenIddict might do, it's to offset the expiration time with a configurable value and a sane default so you don't have to do it, but still it's questionable if it's the right thing ™️