Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Openiddict beta: OpenIddictUser no more present #25

Open
Myrmex opened this issue Oct 26, 2016 · 10 comments
Open

Openiddict beta: OpenIddictUser no more present #25

Myrmex opened this issue Oct 26, 2016 · 10 comments

Comments

@Myrmex
Copy link

Myrmex commented Oct 26, 2016

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
Copy link
Contributor

@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
Copy link
Author

Myrmex commented Oct 27, 2016

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

@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
Copy link

jdosullivan commented Nov 18, 2016

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
Copy link
Contributor

I know the time of creation

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

@jdosullivan
Copy link

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
Copy link
Contributor

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
Copy link

Bartmax commented Jun 1, 2017

@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 ™️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants